Users & roles

ActionConnect uses role-based permissions. This guide explains how to manage the people in your organization and control what each of them can do.

Users, agents, and teams

• A user (or agent) is a member of your organization who signs in to the tenant app.
• Teams group users together for assignment, workload balancing, and notifications. A user can belong to more than one team.

Roles and permissions

A role is a named bundle of permissions. Permissions determine what a user can see and do — for example, manage tickets, configure automations, edit settings, or administer users. You assign one or more roles to each user, and their effective permissions are the union of those roles.

System roles (such as an admin role) are seeded at provisioning. You can create additional roles tailored to your team — for instance a Support Agent role that can work tickets but not change organization settings.

Module-based access

Permissions also control which modules a person can use, so a role can be scoped to just one area of the product. For example, a Facilities Only role grants access to the Facilities section and nothing else — that user sees the Facilities area but not tickets, projects, or settings. Build module-scoped roles when a team only ever works one part of ActionConnect.

This module scoping carries through to reporting: a user only sees the report kinds and dashboard widgets for the work types they have access to. See Reports and Dashboards.

Inviting and managing users

1. Invite a user by email; they receive an invitation to join.
2. Assign roles to grant the right permissions.
3. Add them to teams for assignment and workload.
4. Deactivate users who leave so they can no longer sign in, without deleting their history.

Designing a role model

• Follow least privilege: grant only the permissions a role truly needs.
• Separate agents (work tickets and items) from admins (configure the organization).
• Use teams for who gets work, and roles for what they can do — they are independent levers.

Picker visibility (which roles appear in people pickers)

By default, every people picker — Requested by, Assigned to, and Shared with — lists all eligible users. You can narrow this per work type so each picker only offers the roles that make sense for it. This is managed in Settings → People & Access → Picker Visibility.

The control is a matrix of work type × field:

• Work types — Tickets, Projects, Action Items, Work Orders, and Change Management.
• Fields — Requested by, Assigned to, and Shared with.

For each applicable cell, tick the roles allowed to appear in that picker. Leave a cell empty to allow all roles (the default, and backward compatible).

NOTE

Not every cell applies. Shared with exists only for Action Items; Requested by is a role-based user picker only for Change Management (Tickets and Work Orders use a free-text / contact requester instead). Non-applicable cells are shown disabled.

Picker visibility is a convenience filter, not a security boundary — it tidies the pickers but does not itself restrict access. Use roles and permissions (above) for actual access control.

How this differs from the platform admin console

The roles you manage here govern your organization's users inside your tenant app. They are entirely separate from the platform admin console, which is ActionConnect staff tooling with its own strong-auth role gate and never mixes with your tenant's permissions. See Platform admin console.

Tips

• Define a small number of clear roles rather than many overlapping ones.
• Review role assignments periodically, especially after reorganizations.
• Combine roles with Automations to route work to the right teams automatically.