Skip to content

Admin — Overview

ℹ️ Overview:
  • The Admin module provides features available only to administrators.
  • It enables control over how users access, view, and interact with system modules.
  • Two key components within this module are Roles and Groups, which together define the system’s access model.

Roles

🎯 What are Roles?
  • Roles are collections of permissions that define what a user can see and do within the system.
  • Each role specifies access rights, landing pages, and module visibility.

Key Capabilities

  • Create, edit, and delete roles.
  • Assign roles to users or to groups.
  • Configure a Default Landing Page — the page a user sees immediately after login.
  • Choose which Modules are visible for that role.
  • Audit every role-related action (create, assign, edit, delete).
💡 When to Use Roles:
  • To ensure consistent permissions across multiple users.
  • To restrict or expand access to specific system modules.
  • To streamline user onboarding — assign one role, and the user instantly gains the correct access.

Groups

👥 What are Groups?
  • Groups are collections of users that can be managed as a single unit.
  • Admins assign roles to groups so that all members automatically inherit those permissions.

Key Capabilities

  • Create, edit, and delete groups.
  • Add or remove users as members.
  • Assign roles at the group level (members inherit permissions and landing page).
  • Configure Default Landing Page and Modules for the group.
  • Audit group-related activities (creation, member changes, role assignments, deletions).
🧭 When to Use Groups:
  • When managing departments, project teams, or environments.
  • When you want to handle permissions in bulk.
  • When new users should automatically receive specific roles upon joining a group.

Roles vs. Groups

Feature Roles Groups
Purpose Define permissions & access Organize users for simplified management
Assigned To Users or Groups Users (members)
Landing Page Can be set per role Can be set per group
Module Visibility Defined during role creation Inherits from assigned roles and group settings
Best Practice Defines what users can do Defines who gets those roles
✅ Tip: Combine Roles and Groups to create a scalable, modular permission structure that’s easy to maintain.

Best Practices

🧩 Recommendations:
  • Define clear roles — e.g., JobSubmitter, FinanceViewer — with distinct purposes and minimal overlap.
  • Assign roles to groups instead of individual users for better scalability and easier management.
  • Use landing pages strategically — ensure users start directly on their most relevant module (e.g., Jobs, Spendboard, Dashboard).
  • Audit regularly to remove outdated or redundant roles and groups.

Example Workflow

🧠 Example Scenario:
  • Objective: Configure access for the Data Science Team to submit and manage jobs efficiently.
  1. Create a Role — JobSubmitter
  2. Default Landing Page: Jobs

  3. Modules: Jobs, Templates

  4. Create a Group — DataScienceTeam

  5. Default Landing Page: Dashboard

  6. Assign Role to Group

  7. Assign JobSubmitter to DataScienceTeam.

  8. Add Users

  9. Add team members to DataScienceTeam.

Expected Outcome

  • All team members automatically gain the JobSubmitter permissions.
  • They land on the Dashboard after login.
  • They can access Jobs and Templates modules without extra configuration.
  • Centralized permission management ensures easier updates and consistency.

Summary

  • Roles define what users can do.
  • Groups define who receives those permissions.
  • Together, they create a scalable, maintainable user access structure.
🌟 Best Practice Recap:
  • Keep your roles minimal and purpose-specific.
  • Always assign roles to groups, not directly to users.
  • Review permissions quarterly to ensure alignment with organizational needs.