Self-deployment touches multiple areas that rely on permissions. This guide gives you a practical map of what access is needed at each step and points you to the official permissions articles for the “how.”
You’ll use this when:

• Creating Event Types and deciding who can create/view them
• Integrating devices and ensuring the right teams can see tracks
• Configuring analyzers and verifying who can see the resulting events
• (Optional) enabling mobile access for field users

Key building blocks (at a glance)

• Permission Sets: Bundles of capabilities you assign to users/profiles.
• Event Categories: Containers for Event Types; category access governs visibility/creation.
• Subject Groups: Collections of devices/subjects; group access governs device/track visibility.
• Users vs. Profiles:
  • Users = standard accounts.
  • Profiles = non-password/shared access for kiosk or shared devices (optional).
• Mobile Access: Add only if you plan to validate or operate on mobile.

Plan your access model (fast exercise)

Spend approximately 20 minutes to sketch a minimum-viable access plan:
 

1. List roles involved in deployment/operations
   e.g., Admins, Control Room/Dispatch, Analysts, Field Rangers
2. Map responsibilities to resources
   1. Events—which roles can create/view which Event Categories?
   2. Devices—which roles can view which Subject Groups (and who can edit subjects)?
   3. Analyzers—who should see/manage analyzer output (often an Analyzer Events category)?
   4. Mobile—who needs mobile access and to what?
3. Create/adjust Permission Sets to reflect that mapping
4. Keep sets minimal (least privilege) and reusable.

Where Permissions matter in Self Deployment

Events

• Access is governed primarily at the Event Category level.
• Ensure intended roles can create and view the Event Types you’re deploying.
• When using Choice fields that rely on “My Data” (subjects/users), make sure those underlying resources are visible to the role.

Before you build Events: confirm which category each new Event Type will live in and who needs access to that category.

Devices

• Device/track visibility is governed by Subject Group access.
• After an integration (Gundi or direct), place subjects in the right groups and include those groups in the appropriate Permission Sets.
• Separate View vs. Admin/Edit device capabilities where helpful.

Before you integrate devices: decide which Subject Groups map to which roles.

Analyzers

• Analyzer outputs are stored as Events. Make sure analyzer output goes to an active Event Category that your target roles can access.
• If analyzers reference Subject Groups or Feature Groups, ensure the relevant roles can see those inputs as well (for context).

Before you enable analyzers: confirm the destination Event Category and viewer/editor roles.

External systems & API (as needed)

• Keep tokens scoped and rotated (principle of least privilege).
• Decide who owns/maintains tokens and integrations (not everyone needs this).

Minimal setup sequence by Self Deployment 

• Map Layer Configuration: (Usually no role changes unless your org restricts map assets; if so, include relevant view permissions.)
• Event Configuration: confirm Event Category access for the roles who will create/use the new Event Types.
• Device Configuration: confirm Subject Group access for roles who need to view tracks.
• Analyzer Configuration: confirm destination Event Category access for roles who must see analyzer events.

Validate permissions naturally (optional)

When you run the Self Deployment Guide validation steps (Events, Devices, Analyzers), sign in with any real role account that already represents the intended Permission Set(s). If you prefer not to use a live account, you can create a temporary profile with the same sets. Either way, the goal is simply to verify visibility matches your plan—no special “test user” is required.