Creating and managing Roles and Permissions

 

Before adding employees, consider the duties of your security guards and managers. TrackTik's Permissions allow you to create custom access levels for users. You can modify permissions at any time.

TrackTik provides a variety of permissions settings that can be tailored to meet specific needs. Permissions such as 'Manage the employee timekeeping settings' allow assigning employees to sites, while 'View Customer journal Entry' affects access to journal entries. However, be aware that some permissions, like those needed for accessing certain data models, can only be assigned via APIs. It's crucial to ensure permissions align with access needs to avoid issues like 'Access Denied' errors. System administrators are responsible for assigning these permissions to appropriate roles.

Select Roles & Security and then the "Roles/Permissions" tab to create, modify, or remove roles from the Settings tile.

Key distinctions:

• Superuser tag: Required to see specific roles/permissions in the portal and to edit default roles.
• Administrator role: Provides broad access but does not automatically include superuser capabilities.
• Editing default roles (Guard, Manager, Client): Requires superuser.
• Granting permissions: Only a system administrator with sufficient rights (often superuser) can enable/disable permissions and update roles. If you cannot see or edit permissions, request superuser review from your system admin.
• Report template creation: Template creation is controlled at the region level. Users who need to create or edit custom report templates at a site must also have report creation permissions at the region level. Users without region-level creation permissions will not be able to create templates at the site.

 

See the table below to learn about the types of roles available.

FAQs and Best Practices regarding Roles and Permissions:

When configuring integrations, apply least-privilege practices:

• Provide only the required data objects (for example, Skills, Skill Categories, Employees, Employee Skills, Employment Profiles, Payroll Adhocs) and avoid exposing sensitive fields such as pay rates unless absolutely necessary.
• Create a dedicated integration role/user with only the permissions needed; do not reuse full Admin accounts.
• If limited UI access is required, mirror the integration role in the UI so the human counterpart sees only what is necessary.
• Review and audit the integration’s access on a regular basis to ensure sensitive data (for example, client rates) remains restricted.

You cannot remove a role from an employee on the employee edit page because of a save-time validation check. Manage role assignments via the Roles & Permissions screens.

• To revoke a role: open Settings → Roles & Security → Roles/Permissions, select the role, then remove the employee from the role’s assignments or deactivate the role for that user.
• Termination best practice: assign a dedicated “Terminated” role or revoke all non‑essential roles for the user to immediately limit access.
• Bulk updates: to update roles by job code or process multiple terminations, use the employee import sheet or the bulk API to update role assignments.

Access to many features within TrackTik is controlled by the Roles & Permissions settings. Security guards typically have a "Guard" role, which may restrict their access. To enable them access certain functionalities, like for example the ability to view Account Notes, please follow these steps:

1. Review and Adjust Roles:
   • Navigate to Settings > Roles & Security > Roles/Permissions.
   • Select the relevant staff role (e.g., Guard) and check the permissions.
2. Modify Permissions:
   • Look for permissions related to viewing site information or journal entries, such as “View Customer Journal Entry.”
   • If this permission isn’t enabled, add it and save your changes.
3. Assign Updated Role:
   • Ensure that all affected employees are assigned this updated role.
   • Confirm they are correctly assigned to their respective sites/zones.

Assigning multiple roles to a single employee

You can assign more than one role permission to a single employee. However, doing so can create access conflicts or grant broader permissions than intended. Use multi-role assignments sparingly and prefer creating a single custom role that includes all needed permissions.

Recommended approach (create a custom role):

• Identify the exact tasks and permissions the employee needs. List them clearly.
• In your admin portal, navigate to Roles & Security (Roles/Permissions or Access Control).
• Create a new role, give it a descriptive name, and select only the permissions required for the employee’s duties.
• Save the role and assign it to the employee from their user profile.
• Test the employee’s access (for example, by having them sign in and attempt the tasks or using an admin "impersonate" mode if available) and refine the role if needed.

If you must assign multiple roles:

• Go to the employee’s profile in the admin portal and find the Roles or Access section.
• Add the required roles one by one and save.
• Understand that overlapping permissions across roles are often additive. This can result in more access than expected.
• Avoid mixing roles that contain conflicting restrictions or workflows.
• Document which roles were added and why, including start and end dates if access is temporary.
• Maintain a simple role matrix to track overlaps and understand how your environment resolves permission conflicts.

Best practices to prevent conflicts:

• Follow the principle of least privilege: only grant what’s necessary for current responsibilities.
• Keep roles simple and non-overlapping. If two roles routinely need to be combined, consider merging them into one custom role.
• Review access regularly (for example, after role or assignment changes, or once per quarter). Remove roles that are no longer needed.
• If an employee reports access issues, remove one role at a time to isolate the problem. Consolidate permissions into a single custom role once you know what’s required.

When to use multiple roles:

• Short-term projects or temporary coverage where a second role is needed for a limited time.
• Cross-site or cross-department duties where a custom role isn’t ready yet.

If you have the Administrator role but cannot see the Permissions section under Roles & Permissions, Superuser access is required to view that section.

• What to do:
• Request Superuser access from an existing Superuser or your primary account administrator.
• After Superuser is enabled, sign out and sign back in.
• Return to Roles & Permissions; you should now be able to view and manage permissions.

Note:

• Administrative capabilities vary by role. Superuser is the elevated level needed for viewing and editing the permissions matrix.

If you cannot find the necessary permission or if enabling it does not resolve the issue, please escalate this matter by contacting your TrackTik client success representative or technical support for further assistance.

If users encounter a 403 ERROR when accessing certain modules, the role may be blocked from using the API those modules require. Features such as Data Lab, the new conditional report UI, and Dispatch rely on API access.

There is a way to resolve the issue without elevating users to Administrator:

• Identify the role with issues (for example, District Manager).
• Edit the role under Roles & Security > "Roles/Permissions":
• Click the role you want to adjust, and head to IP Block Scenario
• Enable API access for the role if a specific permission or toggle exists. (Swap it from Block to Grant)

• Grant module-level permissions for the affected features (Data Lab, conditional report UI, Dispatch) as needed.
• Save changes and have users sign out and sign back in.

Security tips:

• Grant only the minimum API and module permissions required.
• Test with one user before applying changes broadly.

If your configuration does not display an explicit “API Access” setting, ensure the modules themselves are enabled and that the role has all dependent permissions those modules require.

If a user cannot view Maps or location data

 their role likely lacks the required mapping permissions. Use the steps below to resolve the issue:

1. Identify the role:
   • Go to Settings > Users, select the user, and confirm the assigned role(s).
2. Grant map permissions:
   • Navigate to Settings > Roles & Security > Roles/Permissions.
   • Open the role and enable the relevant permission(s), such as “View Maps/Geolocation” or equivalent mapping access.
3. Save and re‑test:
   • Have the user sign out, sign back in, and reload the Maps page.

Additional checks:

• Ensure the user has site access to the locations they’re trying to view.
• Verify the Maps module is enabled for your account.

Allowing users to edit mobile app restriction settings

To enable a user to edit mobile app restriction settings, be aware of the current limitation and grant the required permission.

• Current limitation: The ability to edit mobile app restrictions is controlled by the Customer permission “Create/Edit a customer.”

1. Grant the permission:
   • Go to Settings > Roles & Security > Roles/Permissions.
   • Select the user’s role.
   • Enable Customer > Create/Edit a customer.
   • Save and have the user sign out and sign back in.

Considerations:

• Granting this permission provides broader access beyond mobile app restrictions. Apply the principle of least privilege and assign it only to trusted administrative users.
• If you cannot widen access, have an existing administrator make the required changes on behalf of the requestor.

Troubleshooting: Visitor Management not visible in Staff Portal

• Symptom: Staff Portal users cannot see Visitor Management on a site dashboard, even though their permissions are enabled.
• Required license check: Ensure the site has an active Onsite License. Without an active Onsite License at the site, Visitor Management will not appear to staff users.

How to check:

1. Open the site profile in the Admin Portal.
2. Review the Licenses/Subscriptions section and confirm the Onsite License is active for the site.
3. If inactive, activate/assign the Onsite License to the site.
4. Confirm the user is assigned to the site and their Staff Portal role includes relevant Visitor Management permissions.
5. Have the user sign out and sign back in, then refresh the dashboard.

If you cannot approve Mobile Dispatch tickets, verify that the role has the required permission:

• Required permission: Add/View Billing Notes
• Why this matters: Approving Mobile Dispatch tickets requires this permission; if it is disabled, the approval action will be blocked.

How to enable:

1. Go to Settings > Roles & Security > Roles/Permissions in the Admin Portal.
2. Open the role assigned to the user who needs to approve dispatches.
3. In the permission search, type "billing notes" and enable Add/View Billing Notes.
4. Save the role.
5. Have the user sign out and sign back in, then try again.

Mobile Dispatch permissions: view-only limitation

Current limitation: There is no granular permission to restrict users to view-only access for the following areas within Mobile Dispatch:

• Schedule Templates
• Template Assignments
• Patrol Price Settings

What this means:

• You cannot grant "view-only" for these specific modules while allowing others to edit.

Workarounds:

• Limit who is assigned to roles that include access to Mobile Dispatch configuration.
• Create separate roles for schedulers/dispatchers who must edit, and more restricted roles for users who should not access these areas at all.
• Establish internal SOPs for change control and auditing.

Resolving missing tables in Data Lab

If you can open Data Lab but specific tables are not available when building dashboards or queries, the issue is usually related to Data Lab’s dataset/table-level permissions. These permissions are separate from standard web module access.

Why this happens:

• Role permissions for the web UI do not automatically grant access to Data Lab tables.
• Data Lab uses its own access control lists (ACL) for datasets/tables and may also respect site, region, or customer scoping.
• Some datasets are restricted or sensitive and require explicit approval.

Steps to resolve:

1. Verify Data Lab module access. Ensure the user’s role includes access to Data Lab/Analytics.
2. Grant table/dataset permissions. In Admin/Settings > Data Lab (or Analytics) Permissions, assign the required datasets/tables to the user’s role or to the user directly. Confirm the role’s site/region/customer scoping aligns with the data you expect to see.
3. Refresh schema and re-authenticate. In Data Lab, refresh the data catalog/schema after changes. Have the user sign out and sign back in.
4. Validate with a simple query. Attempt a SELECT/preview on the specific table to confirm access.
5. Handle restricted datasets. If a dataset is flagged as restricted, submit a request to gain access and include your use case and intended audience.