LogoLogo
Developers
  • Welcome
  • Introduction
  • Getting Started
    • Overview
    • What can we do?
    • Features & Packages
    • SDKs
  • SERVICES
    • Introduction about services
    • Identity
      • Brand
        • Examples
        • How to identify a brand
        • What default values when a brand is created?
        • How to be a reseller
        • Multiple Brand Management
      • User *
        • User Type
        • Username
        • User Status
        • Username vs. Login Name
        • Password
          • User-defined options
          • Built-in policies
        • Authentication Methods
          • Traditional Login
          • External Login
          • Login with Email link
        • Referral (Invite Friends)
          • Example
        • Password Policy
        • Login with Google
      • Device
        • Type
        • Device Identifier (Device Code)
        • Device Registering
        • Access Limit
    • Subscription
      • What is Package?
      • Package (Pricing Plan)
      • Plans & Pricing *
        • Licensing *
        • Subscription Type *
        • Feature
          • Examples
        • Package
        • Price *
        • Coupon
        • License
          • License Status
          • License Delivery Type
          • License Source
        • Pseudo Flow *
          • Licensing Flow *
          • Pricing Flow *
          • Coupon Application Flow *
    • Billing
      • Payment
        • Payment Status
        • Commission
        • Instant Payment Notification (IPN) *
          • Payment Gateway
          • Supported Gateways
        • Payment Transaction Overview
      • Transaction *
      • Invoice *
    • Wallet
      • Wallet *
        • Secure Practices *
        • ✔️Pseudo Flow *
      • Redeem *
    • Security
      • Black List
      • Risk Levels
    • Community
      • Issue
        • Examples
        • Pseudo Flow
      • Organization
    • Content Delivery Network (CDN)
      • CDN
        • CDN Storage
        • Uploading files to a CDN
        • Downloading files from a CDN
        • Are There Any Limitations?
        • Best Practices
    • Analytics
      • Tracking
        • Tracking Activity
        • Tracking Email
        • Tracking Notification
      • Log & Debug
      • Notification
    • Integration
      • Authentication
      • Payment Gateways
      • Push Notification
      • SMS Provider
      • SMTP Provider
      • Gitbook
    • Brand Settings (Branding)
      • What are Permissions and Roles?
        • System permissions & brand-based permissions
          • A (6 resources)
          • B (7 resources)
          • C (4 resources)
          • D (3 resources)
          • E (2 resources)
          • F (1 resource)
          • I (3 resources)
          • L (1 resource)
          • O (1 organization)
          • P (4 resources)
          • R (1 resource)
          • S (2 resources)
          • T (4 resources)
          • U (7 resources)
          • W (1 resource)
        • System Roles & Brand-based Roles
        • Granting Permissions
        • Assigning Roles
        • Best Practices
        • Pseudo Flow
        • Conclusion
      • What is Issue Category
      • What is Feature?
      • What is Subscription Type?
      • What is Subscription?
      • What is Commission Rate?
      • Events & Patterns
        • Event
          • Events for Community (Organization) (4)
          • Events for Device (3)
          • Events for License (2)
          • Events for Payment (8)
          • Events for System (9)
          • Events for Ticket (Issue) (6)
          • Events for User (47)
            • User.Account_ (5)
            • User.Coupon_ (1)
            • User.Email_ (5)
            • User.Expiration_ (3)
            • User.Inactive_ (2)
            • User.Invoice_ (1)
            • User.License_ (1)
            • User.Logged_ (3)
            • User.Password_ (3)
            • User.Phone_ (2)
            • User.Profile_ (2)
            • User.Receipt_ (1)
            • User.Referee_ (1)
            • User.Registered (2)
            • User.Reward_ (3)
            • User.Service_ (1)
            • User.SMS_ (1)
            • User.Status_ (5)
            • User.Suspicious_ (4)
            • User.Ticket_ (1)
          • Events for Wallet (4)
          • (Missing Events) *
        • WalletEarningEvent
          • Earning.User_ (8)
          • Earning.Wallet_ (2)
        • Email Templates *
        • SMS Templates *
      • Tags
      • Domains
      • Email templates
    • System Constants (Read-only)
      • Country
      • State
      • City
      • Time Zone
      • Currency
      • Language
      • Exchange Rate
  • Other concepts
    • Built-in resource
      • Built-in roles
        • Best practice
      • Built-in permissions
    • JFW Status
    • Default data
    • System data
    • Soft deletion data
    • Cryptography
    • Mailing
      • Examples
      • Email Sender
      • Email Template
    • Scheduler
      • Examples
      • Schedulers Used In JFW
    • Tracking Level
  • Versioning
  • Workflows
  • References
    • Internal references
    • External references
      • MailKit
      • MIME Type
  • Changelog
Powered by GitBook
LogoLogo

For developers

  • Developers

For users

  • Admin & cPanel

Examples

  • BoostPTE

Copyright @2018-2025

On this page
  • Best Practices for Using Built-in Roles in Jframework
  • 1. Understand the Purpose of Each Role
  • 2. Follow the Principle of Least Privilege
  • 3. Use Role Hierarchies Effectively
  • 4. Avoid Overusing the Super Admin Role
  • 5. Regularly Audit Role Assignments
  • 6. Customize Roles When Necessary
  • 7. Train Users on Role Responsibilities
  • 8. Monitor and Analyze Role Usage
  • 9. Plan for Scalability
  • 10. Document Your Role Management Strategy
  • Conclusion

Was this helpful?

  1. Other concepts
  2. Built-in resource
  3. Built-in roles

Best practice

Best Practices for Using Built-in Roles in Jframework

Built-in roles are a powerful feature of JFW system, enabling you to manage access and permissions efficiently. However, to maximize their potential, it’s essential to follow best practices. This post outlines key strategies for using built-in roles effectively, ensuring security, scalability, and ease of management.


1. Understand the Purpose of Each Role

Before assigning roles, take the time to understand the purpose and permissions of each built-in role. Here’s a quick recap:

  • Super Admin: Full system control, including global settings and all brands.

  • Brand Owner: Full control over a specific brand’s resources.

  • User Manager: Manages users, roles, and permissions within a brand.

  • Reader: Read-only access to brand information.

  • Support Staff: Handles customer support tasks and accesses error logs.

  • Billing: Manages financial transactions and subscriptions.

  • Marketing: Manages campaigns, ads, and user engagement.

Best Practice: Assign roles based on the user’s responsibilities. Avoid granting excessive permissions that go beyond their job requirements.


2. Follow the Principle of Least Privilege

The Principle of Least Privilege (PoLP) is a security concept that ensures users have the minimum level of access necessary to perform their tasks.

  • Example: A marketing team member should not have access to billing information or system logs.

  • Implementation: Use the Reader role for users who only need to view data, and the Support Staff role for troubleshooting without granting edit permissions.

Best Practice: Regularly review role assignments to ensure users do not accumulate unnecessary permissions over time.


3. Use Role Hierarchies Effectively

Built-in roles are designed with a hierarchy in mind. For example:

  • Super Admin > Brand Owner > User Manager > Support Staff > Reader.

Best Practice: Leverage this hierarchy to delegate responsibilities. For instance, a Brand Owner can manage their brand’s resources, while a User Manager handles user-specific tasks.


4. Avoid Overusing the Super Admin Role

The Super Admin role has unrestricted access to the entire system. While it’s powerful, it should be used sparingly.

  • Risk: Overuse of the Super Admin role increases the risk of accidental changes or security breaches.

  • Solution: Reserve this role for a small group of trusted administrators. For day-to-day tasks, use lower-level roles like Brand Owner or User Manager.


5. Regularly Audit Role Assignments

Over time, role assignments can become outdated as users change roles or leave the organization.

  • Action: Conduct regular audits to ensure roles are assigned correctly.

  • Tool: Use the system’s logging and reporting features to track role changes and access patterns.

Best Practice: Automate audits where possible, and set up alerts for unusual activity (e.g., a user gaining Super Admin access unexpectedly).


6. Customize Roles When Necessary

While built-in roles cover most use cases, there may be situations where custom roles are needed.

  • Example: A hybrid role that combines Support Staff and Marketing permissions for a specific team.

  • Implementation: Use the system’s role customization features to create tailored roles without compromising security.

Best Practice: Document custom roles and their purposes to maintain clarity and avoid role duplication.


7. Train Users on Role Responsibilities

Ensure that users understand the permissions and limitations of their assigned roles.

  • Example: A Reader should know they cannot edit data, while a User Manager should understand their responsibility for managing permissions.

  • Training: Provide role-specific training and documentation to avoid misuse.

Best Practice: Include role-based training as part of the onboarding process for new users.


8. Monitor and Analyze Role Usage

Use the system’s monitoring tools to track how roles are being used.

  • Metrics to Track:

    • Frequency of role changes.

    • Access patterns for sensitive features.

    • Unusual activity (e.g., a Reader attempting to edit data).

  • Action: Use this data to identify potential security risks or inefficiencies.

Best Practice: Set up dashboards to visualize role usage and highlight areas for improvement.


9. Plan for Scalability

As your organization grows, your role management strategy should scale accordingly.

  • Action: Regularly review and update your role structure to accommodate new teams, brands, or features.

  • Example: If a new department is added, create custom roles or adjust existing ones to meet their needs.

Best Practice: Design your role structure with future growth in mind, ensuring flexibility and adaptability.


10. Document Your Role Management Strategy

Maintain clear documentation of your role management practices, including:

  • Definitions of each built-in role.

  • Guidelines for assigning roles.

  • Procedures for auditing and updating roles.

Best Practice: Share this documentation with your team to ensure consistency and transparency.


Conclusion

Built-in roles are a cornerstone of secure and efficient access management in your system. By following these best practices, you can ensure that roles are used effectively, minimizing risks and maximizing productivity.

Key Takeaways:

  • Assign roles based on responsibilities.

  • Follow the Principle of Least Privilege.

  • Regularly audit and update role assignments.

  • Train users and document your strategy.

By implementing these practices, you’ll create a robust and scalable role management system that supports your organization’s goals.

Last updated 1 month ago

Was this helpful?