Skip to content

Permission Keys & Terminal Access

PulseCAD controls what a member can do with three separate access layers. They stack, and they answer different questions. Understanding how they combine is the key to onboarding a beta team cleanly, so this page walks through each layer and then shows how they fit together.

Three layers, three questions

  • Membership role - how much authority you have in the community (owner down to read-only).
  • Terminal Access - which consoles (terminals) you are allowed to open.
  • Department Roles - which department, rank, and specialty capabilities you carry inside a terminal.

A member needs the right combination of all three to actually do a job. Owners and admins are the exception - they are privileged and see everything.

Layer 1 - Membership role

Every member of a community holds one membership role, highest to lowest:

owner → admin → supervisor → member → readonly

This is the baseline authority level. owner and admin are privileged: they can open the Admin Console, and they see every terminal and every department regardless of the other two layers. Supervisor, member, and readonly are operational roles - their day-to-day access is shaped by the next two layers.

Membership role is always assigned manually, per member, from Admin → Members (the Role dropdown). It is never handed out by a permission key. See the walkthrough below for why that matters.

Layer 2 - Terminal Access grants

Terminal Access decides which terminals a member can open. It is set per member in Admin → Members, in the Terminals column. A member only sees the hub tiles for terminals they have been granted. The terminals are:

Terminal What it is
Dispatch The dispatch board and 911 queue - see Dispatch
Law Enforcement The LEO MDT - see MDT
Fire & EMS The Fire/EMS console - see Fire & EMS
Tow & DOT The tow/recovery console - see Tow & DOT
Civilian The resident/DMV portal - see Civilian Portal
Court The judicial surface - see Court
Records The Records Console

Terminal Access is orthogonal to role. A supervisor with only the Fire & EMS terminal granted cannot open the LEO MDT; a plain member granted Dispatch and Records can open both. Grant a member exactly the terminals their job needs.

Open the Civilian portal to everyone

There is a community-wide allowPublicCivilians toggle. Turn it on and the Civilian portal is open to every member (and, depending on your join policy, to new joiners) without granting the Civilian terminal to each person individually. Leave it off if you want civilian access to be per-member like the other terminals.

Layer 3 - Department Roles

Opening a terminal is not the same as being cleared to work a department inside it. Department Roles are custom roles you build per department. Each one carries:

  • a rank tier (your department's ladder - for example Cadet, Officer, Sergeant, Command), and
  • a set of capabilities - specialty clearances such as K9, SWAT, or FTO.

You define these when you set up each department (see Admin → Departments). A member can hold department roles in one or more departments.

Department roles are granted two ways:

  1. Manually, per member, from Admin → Members in the Dept Roles column.
  2. By redeeming a Permission Key (next section).

Permission Keys

A Permission Key is a shareable code that carries a bundle of department roles. Instead of editing every member by hand, you mint one key, share it, and let members redeem it to gain the roles it carries. Manage keys in Admin → Community → Permissions.

What a key can and cannot grant

Permission Keys grant department roles ONLY

A Permission Key can never grant admin or owner. Membership role is always assigned manually, per member, from Admin → Members. This is a hard rule: a key redeemed by anyone - stranger or staff - only ever adds the department roles bundled into it, never elevated authority over your community.

A key with no roles attached is therefore just a plain join / read-only key: redeeming it makes someone a member with nothing granted, which you can then build on manually.

Minting a key

From Admin → Community → Permissions, create a key and choose:

  • The department roles it carries - pick any set of your custom department roles across any departments. (Leave empty for a plain join key.)
  • Max uses - how many times it can be redeemed before it stops working. Leave blank for unlimited.
  • Expiry - an optional date after which the key stops working.

Share the resulting code with the people who should receive those roles. They redeem it from the Portal.

Editing, expiry, and revoking

Editing a key affects future redemptions only

Changing the roles on an existing key changes what future redemptions grant. Members who already redeemed the key keep exactly what they got at the time - editing the key never reaches back and changes or removes their roles.

  • Max uses and expiry both simply stop the key from being redeemed once the limit or date is reached.
  • Revoking a key stops future redemptions. It does not claw back roles from members who already redeemed it - remove those from each member individually in Admin → Members if you need to.

The + Invite Member button in Admin → Members produces something different: a role-less join link. Whoever opens /join/{code} lands in your community as a read-only civilian - no terminals, no department roles. You then build their access up from there: grant terminals, assign department roles, or hand them a permission key.

Permission Key (Admin → Community → Permissions) Invite Link (Admin → Members)
Carries department roles Yes (a chosen bundle) No
Grants admin/owner Never Never
Result on redeem Member with the key's department roles Read-only civilian
Best for Onboarding a whole department at once Letting a specific person in, then configuring by hand

Both respect your community join policy (see Admin → Community).

How to onboard your team

A clean first-run sequence that uses all three layers:

  1. Create your departments and their roles. In Admin → Departments, add each agency, then build its department roles (rank tiers plus capabilities like K9, SWAT, FTO).
  2. Set your join policy. In Admin → Community, decide whether the community is open, code-gated, or invite-only.
  3. Mint a permission key (or an invite link). For a whole department, mint a Permission Key in Admin → Community → Permissions carrying that department's roles. For a single hand-picked person, use + Invite Member and configure them afterward.
  4. Assign terminals. In Admin → Members, grant each member the Terminals they need (or flip on allowPublicCivilians for open civilian access). Set anyone who should administer the community to admin here as well - remember, no key can do that for you.
  5. Members go on duty. Once a member has a terminal and the department roles for it, they open the terminal from the hub and go on duty in their department.

Revisit as ranks change

Promotions, new specialties, or moving someone between departments are all edits in Admin → Members (or a fresh permission key). Because edits to a key never rewrite past redemptions, mint a new key when a department's role bundle changes and let it supersede the old one.