User Roles & Permissions

Control what users can see and do in Hidma through role-based access control.

🎥 Video Tutorial

Watch the Video

Learn how to assign system roles and team roles to users in Hidma.

Overview

Hidma uses role-based access control (RBAC) to determine what each user can see and do within the system. Every user must be assigned at least one role to operate within Hidma - roles define permissions like viewing clients, creating projects, logging time, generating bills, managing users, and accessing system settings. Without roles assigned, a user account exists but cannot perform any meaningful actions.

Roles come in two distinct types: system roles that apply organization-wide regardless of team membership, and team roles that grant permissions specific to individual teams. This dual structure lets you create flexible permission schemes where someone might be an HR manager across the entire organization (system role) while also serving as a team manager for the Accounting team and a team member of the Admin team (team roles). Understanding the distinction between these role types and how they work together is fundamental to properly managing user access.

Role Types

System Roles

System roles grant permissions across the entire Hidma organization without regard to team boundaries. When you assign a system role to someone, they receive those permissions for all clients, projects, users, and data in the system - not just what's associated with specific teams. System roles represent organization-wide responsibilities and authority levels.

Super User The highest-level role with complete access to everything in Hidma. Super users can view, create, modify, and delete any data; access all system settings and configuration; manage users and roles; view all financial information; and perform any action available in the system. This role should be reserved for system administrators and key management personnel who need unrestricted access for configuration, troubleshooting, and oversight.

Super users see everything regardless of team assignments or project sharing - they have implicit access to all data and all functionality. This level of access is powerful and should be granted judiciously to maintain proper data security and confidentiality.

HR Manager A role focused on user management and team administration without requiring full system access. HR managers can create and edit user accounts, assign roles to users, manage team memberships, view user profiles and employment information, and configure HR-related settings. They do not necessarily have access to financial data, billing, or client information unless separately granted through additional roles.

This role is appropriate for human resources staff who manage personnel without needing involvement in client work, projects, or billing. They can onboard new employees by creating accounts and assigning appropriate roles, reorganize teams as the company structure evolves, and maintain accurate user information throughout the organization.

Other System Roles Depending on your Hidma configuration, additional system roles might include Finance Manager (access to all financial data and billing across the organization), Administrator (configuration access without full super user privileges), or custom system roles defined for your specific organizational needs.

System roles appear in the role selection dropdown when you're assigning roles without selecting a specific team first - they're the organization-wide options that apply broadly rather than to particular team contexts.

Team Roles

Team roles grant permissions within the context of specific teams. Unlike system roles that apply everywhere, team roles limit access to the clients, projects, and work associated with particular teams. A user can have different team roles for different teams - perhaps they manage the Tax team while being just a member of the Advisory team.

Team roles require both a team selection and a role selection. You choose "Accounts team" and "Team Manager," creating a combination that means "Manager of the Accounts team" rather than "Team Manager across the entire organization."

Team Manager Within their team, team managers can create and manage projects for the team's clients, assign work to team members, view all team members' time entries and approve timesheets, manage budgets and project settings, access financial information for team projects, and configure team-specific settings. They have administrative control over their team's work without necessarily having access to other teams' projects or organization-wide settings.

Team managers typically lead practice areas, departments, or functional groups. They need authority to run their team's operations, manage work allocation, review team productivity, and oversee project delivery, but don't require access to unrelated teams' information or system-wide administration.

Team Member The standard role for people who do billable work on team projects. Team members can view projects shared with their team, log time against team projects, see project details and requirements, view their own timesheets and submit them for approval, and access basic information about team clients. They cannot manage other users' time, modify project settings, create bills, or access financial reporting.

This role provides the essential permissions needed to track work and complete tasks without administrative responsibilities. Most users in a professional services organization are team members - they need to find their assigned projects, log their hours, and submit timesheets, but don't need broader management capabilities.

Viewer A read-only role within the team context. Viewers can see team projects, view time tracked by the team, and access reports and dashboards for team activity, but cannot log time, create projects, or make any changes. This role is useful for stakeholders who need visibility without operational involvement - perhaps partners who want to monitor team activity, administrative staff who need to reference project information, or clients who receive viewer access to track project progress.

Multiple Role Assignment

Users can hold multiple roles simultaneously - this is not only allowed but often necessary to match real-world organizational structures. Someone might be:

• HR Manager (system role) - giving them user management capabilities across the organization
• Team Member of the Admin team (team role) - allowing them to log time on administrative projects
• Team Manager of the Accounts team (team role) - granting them management authority over accounting projects

Each role grants its defined permissions, and the user's effective permissions are the combination of all their roles. When permissions overlap, the more permissive access wins - if one role grants view-only access and another grants edit access, the user can edit.

You can assign up to one team role per team per user. You cannot make someone both a Team Manager and Team Member of the same team - you choose the appropriate level for each team. But you can assign the same user different levels across different teams, reflecting their varying responsibilities in different areas of the organization.

Assigning Roles to Users

Accessing Role Assignment

Navigate to the user's profile by going to Settings > Users and selecting the specific user you want to configure. Look for a "Roles" or "Team Access" section typically found in the user profile interface. This section displays all currently assigned roles and provides controls for adding or removing roles.

If a user has no roles assigned, they'll show an empty roles section and won't be able to access any features in Hidma until you grant them at least one role. New user accounts often start with no roles, requiring explicit assignment before the user can begin working.

Adding System Roles

To assign a system role, click "Add New Team Access" or similar button in the roles section. Leave the team selection empty - do not select any specific team. With no team selected, the role dropdown displays only system roles like Super User and HR Manager.

Choose the appropriate system role from the dropdown. Perhaps you're granting HR Manager permissions to someone in the human resources department. Click Save to assign the role. The user immediately gains the permissions associated with that system role across the entire organization.

The role appears in the user's roles list showing just the role name without a team association, indicating its system-wide scope.

Adding Team Roles

To assign a team role, click "Add New Team Access" again. This time, select the specific team first - perhaps "Admin Team" or "Accounts Team." Once you've selected a team, the role dropdown updates to show team roles like Team Manager and Team Member.

Choose the appropriate role level for this team. Perhaps this user should be a Team Member of the Admin Team - they'll do work on admin projects but won't manage the team. Select "Team Member" and click Save.

The role appears showing both the team name and the role: "Team Member - Admin Team." This combination clearly indicates the user's permission level within that specific team context.

Adding Multiple Team Roles

You can add team roles for multiple teams by repeating the process. Perhaps after making someone a Team Member of the Admin Team, you also want them to be a Team Manager of the Accounts Team. Click "Add New Team Access" again, select "Accounts Team," choose "Team Manager," and save.

The user now shows two team roles in their profile:

• Team Member - Admin Team
• Team Manager - Accounts Team

This configuration reflects their different responsibilities and authority levels across different parts of the organization. They manage the accounting team while participating as a regular member on administrative projects.

Removing Roles

To remove a role assignment, find it in the user's roles list and click the remove or delete button (typically an X icon or trash icon). Confirm the removal if prompted. The role disappears immediately and the user loses those permissions.

Be careful when removing roles - if you remove all of a user's roles, they'll be unable to access any Hidma functionality until you assign them new roles. Make sure users always have at least one role that grants the access they need to perform their work.

Permission Implications

What System Roles Can Do

System roles grant broad access across organizational boundaries:

Super User - Everything. Complete access to all data, all settings, all functionality. Super users bypass all normal permission checks and restrictions.

HR Manager - User management, team organization, role assignment, viewing user profiles and employment data. Typically excludes financial data and client information unless the HR Manager role in your configuration includes those permissions.

What Team Roles Can Do

Team roles grant access within team scope:

Team Manager - Manage projects and work for their team, view and approve team member timesheets, access financial information for team projects, assign work and manage team resources, configure team-specific settings. Limited to their team's projects and clients - cannot see other teams' work unless also granted access to those teams.

Team Member - View team projects they're shared on, log time against team projects, submit their own timesheets for approval, access project details and requirements. Cannot manage others' work or access financial/billing information.

Viewer - Read-only access to team information. Can see projects, view time tracking, access reports, but cannot modify anything or log time.

Permission Combinations

When users have multiple roles, their effective permissions are cumulative:

A user who is both an HR Manager (system role) and a Team Member of the Tax Team (team role) can:

• Manage users and roles organization-wide (from HR Manager)
• View and edit all user profiles (from HR Manager)
• Log time on Tax Team projects (from Team Member role)
• View Tax Team project details (from Team Member role)

But they cannot:

• Manage Tax Team projects (would need Team Manager role)
• Access other teams' projects (would need roles for those teams)
• View all financial data organization-wide (would need Super User or similar role)

Understanding these combinations helps you grant exactly the access needed without over-permissioning.

Timesheet Permissions

Hidma provides granular control over who can view and manage timesheets. These permissions follow a hierarchical structure that respects both team boundaries and role seniority.

Director Protection

Users with the Director role receive special protection for their timesheets:

• Viewing Director Timesheets: Only users with View All Timesheets or Manage All Timesheets rights can view a director's timesheet
• Managing Director Timesheets: Only users with Manage All Timesheets rights can approve, reject, or modify a director's timesheet

This ensures that sensitive time data for senior leadership remains confidential and can only be accessed by users with organization-wide permissions.

Team Timesheet Rights

There are four levels of team timesheet permissions, organized in two tiers:

Standard Team Rights

Right	Description
View Team Member Timesheets	View timesheets of team members who do not have View or Manage rights themselves
Manage Team Member Timesheets	Approve and manage timesheets of team members who do not have View or Manage rights themselves

These standard rights allow managers to view and approve timesheets of their regular team members. However, they cannot see or manage timesheets of other users who also hold timesheet management rights.

Elevated Team Rights

Right	Description
View All Team Timesheets	View timesheets of all users in the team, including those with View/Manage rights (except Directors)
Manage All Team Timesheets	Approve and manage timesheets of all users in the team, including those with View/Manage rights (except Directors)

These elevated rights sit above the standard rights, allowing senior managers to oversee other managers within their team. Users with these rights can view or manage timesheets of everyone in their team—except for users with the Director role.

Permission Hierarchy Example

Consider a team with the following members:

• Sarah - Director
• Mike - Has Manage All Team Timesheets
• Lisa - Has Manage Team Member Timesheets
• Tom - Has View Team Member Timesheets
• Alex - Regular team member (no timesheet rights)

User	Can View Timesheets Of	Can Manage Timesheets Of
Sarah (Director)	Based on her other rights	Based on her other rights
Mike (Manage All Team)	Lisa, Tom, Alex	Lisa, Tom, Alex
Lisa (Manage Team Member)	Alex only	Alex only
Tom (View Team Member)	Alex only	None
Alex (No rights)	None	None

Notice that:

• Mike can view and manage Lisa's and Tom's timesheets because he has the "All" version of the rights
• Lisa and Tom cannot see each other's timesheets because they both have management rights
• Nobody in this table can view or manage Sarah's timesheet—that requires organization-wide rights

Organization-Wide Timesheet Rights

For complete oversight across all teams:

Right	Description
View All Timesheets	View timesheets of all users across the organization, including Directors
Manage All Timesheets	Approve and manage timesheets of all users across the organization, including Directors

These rights bypass team boundaries and role restrictions, providing full visibility and control for administrators and senior leadership.

Standard Report Permissions

Hidma provides granular control over who can access and manage Standard Reports through three specific permissions.

Report Access Levels

Permission	Description
View Standard Reports	Can see and run Standard Reports, but only when those reports have been explicitly shared with the user. By default, users with this permission see no reports until someone shares reports with them.
View All Standard Reports	Can see and run all Standard Reports automatically, including new reports as they're released with monthly updates. No sharing required - reports appear immediately when available.
Manage All Standard Reports	Includes all viewing capabilities, plus the ability to share reports with individual users or entire teams. Can set view or edit permissions when sharing.

Sharing Permissions

When sharing a report, you can grant two levels of access:

Share Level	What It Allows
View	Recipient can see and run the shared report
Edit	Recipient can see, run, and share the report with others

Standard Report Permission Examples

Scenario: Department Head A department head who needs to see all available reports but doesn't manage report access for others should receive View All Standard Reports. They automatically see every report and new reports as they're released.

Scenario: Team Member A team member who only needs specific reports for their work should receive View Standard Reports. Their manager or administrator can then share relevant reports with them, ensuring they only see reports appropriate for their role.

Scenario: Administrator An administrator responsible for managing report access across the organization should receive Manage All Standard Reports. They can share any report with any user or team, controlling who sees what throughout the organization.

Best Practices

Role Management Tips

Principle of Least Privilege Grant users the minimum permissions they need to perform their job responsibilities. Don't make everyone a Super User just to avoid thinking about permissions. A team member who just logs time doesn't need team manager capabilities. Someone who manages one team doesn't need super user access to the entire system. Thoughtful role assignment maintains security and prevents accidental data changes.

Document Role Decisions When you grant someone unusual role combinations or elevated permissions, add notes to their user profile explaining why. Perhaps "Super User access granted per CEO authorization for system administration duties" or "Team Manager for both Tax and Audit teams due to cross-functional project lead responsibilities." Documentation helps future administrators understand permission decisions when reviewing access or troubleshooting issues.

Regular Access Reviews Quarterly or semi-annually, review user roles to ensure they still match current responsibilities. People change positions, responsibilities shift, and projects conclude. Someone might have Team Manager access to a team they no longer work with, or elevated permissions for a project that's completed. Regular reviews identify and remove unnecessary access, maintaining appropriate security boundaries.

Use Team Roles for Most Users Most people in a professional services organization should primarily have team roles rather than system roles. Team-based access naturally maintains appropriate boundaries - tax team members see tax work, audit team members see audit work. Reserve system roles for truly organization-wide responsibilities like human resources, firm-wide administration, or executive oversight.

One Super User Isn't Enough Have at least two or three super users to ensure system administration coverage when people are unavailable. But don't have dozens of super users - the role should be reserved for people who genuinely need unrestricted access for system administration, not granted broadly for convenience.

Match Roles to Real Responsibilities Assign roles that reflect actual job duties, not aspirational or courtesy titles. If someone's title is "Senior Manager" but their actual role is doing billable work without managing others, give them Team Member permissions, not Team Manager. Match permissions to what people actually do, ensuring they have appropriate access without over-permissioning.

Onboarding and Offboarding Make role assignment part of your employee onboarding checklist - new employees should receive appropriate role assignments on their first day based on their position and team. Similarly, offboarding should include role removal or account deactivation to prevent former employees from retaining system access.

Common Scenarios

Scenario: New Team Member Hire

Situation: New accountant joining the Accounting team to do billable work on client projects.

Solution: Create their user account, then assign them Team Member role for the Accounting Team. They immediately can view accounting projects they're shared on and log their time. No system roles needed - they work within the team structure with appropriate permissions for their position.

Scenario: Promoting to Team Lead

Situation: Team member performing well and promoted to lead the Advisory team.

Solution: In their user profile, change their Advisory team role from Team Member to Team Manager. They retain their ability to log time (team managers can also log time) but gain additional permissions to manage the team's projects, approve timesheets, and oversee team operations. No system role needed unless they also have firm-wide responsibilities beyond team management.

Scenario: HR Staff Setup

Situation: Human resources staff member who manages employees but doesn't work on client projects.

Solution: Assign HR Manager system role for user management capabilities across the organization. Do not assign any team roles since they're not tracking time or working on projects. They can manage all user accounts and team memberships without accessing client or financial information.

Scenario: Cross-Functional Project Lead

Situation: Senior manager leading a project involving both Tax and Audit teams.

Solution: Assign Team Manager roles for both Tax Team and Audit Team. They can manage projects and view work for both teams, coordinate cross-functional efforts, and access necessary information across team boundaries. This multi-team manager setup reflects their cross-functional responsibilities.

Scenario: Partner Oversight

Situation: Partner who needs to see all firm activity but doesn't do day-to-day project management.

Solution: Assign Super User role for unrestricted visibility across all teams, clients, projects, and financial data. Partners often need this broad access for oversight, client relationship management, and strategic decision-making even if they're not managing individual team operations.

Scenario: Administrative Assistant

Situation: Assistant who needs to reference project information and view schedules but doesn't track time or manage work.

Solution: Assign Viewer team role for the relevant teams. They can see project details and schedules without ability to modify anything or log time. This read-only access provides the visibility they need for coordination without operational permissions.

Related Topics

• Organizations - Multi-entity setup
• Teams Management - Creating and organizing teams
• User Management - Creating user accounts
• Project Sharing - Project-level access control
• Timesheet Approvals - Understanding timesheet approval permissions
• Reporting & Analytics - Standard Reports and data access

---

Need Help?

Proper role assignment ensures users have appropriate access without over-permissioning. Start with minimum necessary permissions and elevate as responsibilities require.