Agent Roles¶

Roles are the primary mechanism for controlling what agents can see and do within the platform. Each agent is assigned a role that acts as a permission template, granting access to specific areas, ticket types, and actions. Roles can also be used to scope visibility so that agents only see the work relevant to their function.

Pre-Configured Roles¶

The GRC-ITSM platform includes several pre-configured roles designed to support both ITSM operations and GRC-specific workflows:

Administrator¶

Full access to all platform areas including configuration, integrations, and system settings. Administrators can manage agents, roles, teams, ticket types, templates, rules, and all other administrative functions.

Engineer Roles¶

The platform provides scoped engineer roles that control which team's work an agent can access:

This split is particularly useful for organizations where different people handle ConMon operations versus broader compliance governance. An agent working solely on monthly vulnerability reviews doesn't need to see audit preparation tickets, and vice versa. Agents who work across both areas can be assigned the "All Teams" role.

Team Member¶

A general-purpose role with standard access to tickets, the service desk, and day-to-day operational functions. Suitable for agents who work within ITSM support queues (1^st, 2^nd, 3^rd Line Support) without needing access to GRC-specific configuration or compliance areas.

Notifications¶

A specialized role that enables all email notifications for the assigned agent. This is used for agents or service accounts that need to receive notification emails for platform events, ensuring they stay informed about ticket updates, approvals, and escalations.

How Roles Work¶

Permission Inheritance¶

Roles use a highest-access-wins model:

• The role defines the base permissions for the agent
• Individual permissions can be overridden at the agent level, but only to add access
• If the role grants full access to an area, it cannot be lowered at the agent level
• A permission set to "Not Set" at both the role and agent level means no access

This means roles should be designed conservatively: grant the minimum access needed, and use agent-level overrides only when a specific individual needs something beyond what their role provides.

What Roles Control¶

Creating a Role¶

1. Navigate to Configuration > Teams & Agents > Roles
2. Click New
3. Set the role name and configure the permission areas
4. Save the role

Once created, the role can be assigned to agents via the Agent Details tab. Roles can also be mapped to Azure security groups through the Halo Integrator's Microsoft Entra ID synchronization, so agents imported from Entra ID are automatically assigned the correct role based on their group membership.

Best Practices¶

Use roles, not agent-level overrides. Configure permissions at the role level wherever possible. Agent-level overrides are harder to audit and can create inconsistencies when multiple agents should have the same access.

Start with least privilege. Begin with the minimum access needed and expand as requirements become clear. It is easier to grant additional access than to identify and revoke excess permissions after the fact.

Align roles with team structure. The pre-configured engineer roles (All Teams, GRC Team, ConMon Team) mirror the team structure. When creating custom roles, follow the same pattern: define roles that match how the organization divides work.

Review roles periodically. As the organization evolves, roles may need adjustment. Review role assignments as part of periodic access reviews to ensure agents have appropriate access for their current responsibilities. This supports FedRAMP AC-2 (Account Management) and CMMC AC.L2-3.1.1 (Authorized Access Control).