Help Center

Create a role and grant exact permissions

Build a role around real responsibilities, test it safely, and avoid accidental department-wide access.

Understand the outcome

Permissions combine across every role assigned to a member. Plan the role by tasks and data scope before opening the editor.

Core is the required foundation of every Station Clipboard department. It provides sign-in, personnel records, roles and permissions, general settings, Dept Communications (announcements and department email), the department calendar, Workflows automation, notifications, the activity log, module management, and the Support Hub. It is always enabled, and every optional module relies on it for identity, department isolation, and access control.

What this procedure is for

This guide focuses specifically on “Create a role and grant exact permissions.” Complete it from an account with the appropriate Core access, verify it from the affected member or operational view, and preserve existing records rather than repurposing historical configuration.

Before you begin

Make the decision before changing the screen. Record the current configuration when the department already uses this feature, and use a test record or test account when the change can affect active members.

  • List the pages and actions the role must perform.
  • Decide where the role should see only its own records versus all department records.
  • Use a non-administrator test account, or the logged view-as-member mode, to check the result.
If a control is missing

Do not work around it from another member’s account. Confirm that Core is enabled, its dependencies are active, and your role grants the exact management action required for this task.

Where to work and what access you need

Start from the portal destination named in the procedure. Administrators normally need permission to view Core plus the specific create, edit, manage, approve, report, or all-record action used by the task. Visibility alone does not grant management access.

  • Dashboard/dashboard
  • Dept Communications/announcements
  • Scheduled emails/announcements?view=scheduled-emails
  • Calendar/calendar
  • My Profile/profile
  • Personal settings/settings/appearance
  • Personnel/settings/users
  • Add personnel/settings/users/new
  • Certification Hub/settings/users/certifications
  • Roles & Permissions/settings/roles
  • General settings/settings/general
  • Modules/settings/modules
  • Workflows/settings/automations/workflows
  • Workflow approvals/settings/automations/workflows/approvals
  • Activity Log/settings/logs
  • AI Assistant/settings/ai-assistant
  • Support Hub/support-hub

If your department uses custom roles, test the procedure with that role—not only with a full administrator account. This confirms the people responsible for daily operations can complete the workflow without receiving unrelated access.

Complete the task

  1. Step 1Open Roles & Permissions

    Go to Roles & Permissions under Organization and create a role, start from a template, or clone an existing one.

  2. Step 2Define the role

    Enter a clear operational name, description, and color. Avoid vague names such as Extra Access.

  3. Step 3Grant module access

    Turn on access only for modules this responsibility uses. A module being enabled does not grant access by itself.

  4. Step 4Grant exact actions

    Add create, edit, approve, export, settings, or all-record actions only when the role requires them.

  5. Step 5Save and assign

    Save the role, open Personnel, select the member, and assign the role.

  6. Step 6Test effective access

    Confirm both the allowed actions and the intentionally restricted pages.

Operational safeguards

Apply these module-level controls while completing the procedure. They prevent a technically saved configuration from becoming an operational or access problem later.

  • Control point
    Confirm the department timezone before scheduling messages or importing dated records.
  • Control point
    Define stations and apparatus before configuring modules that use those lists.
  • Control point
    Create roles around job responsibilities; avoid giving broad administrator access for one missing action.
  • Control point
    Grant own-record permissions when a member should not see department-wide records.
  • Control point
    Disable departed members instead of deleting them so their history stays intact.
  • Control point
    Run every new workflow as a test run before publishing it.

Verify the result

Do not consider the setup complete merely because the save action succeeded. Confirm the behavior from the user-facing or operational view, then retain evidence of the test when department policy requires it.

  • The role appears on the member’s record.
  • Expected pages and buttons are visible.
  • Other members’ records stay hidden when only own-record access was intended.

If any verification fails, return to the source configuration and correct it there. Do not edit a report or downstream record to conceal an incorrect setup.

Troubleshooting

The member still has access after removing the role

Another assigned role still grants the permission. Review all of their roles.

The page appears but an action is missing

Viewing and acting are separate permissions. Grant the exact action.

The module is absent

Confirm the module is in the subscription, enabled, and has its dependencies enabled.

Related Core capabilities

This task sits inside a larger module workflow. These related capabilities may affect the result or provide the next administrative step:

  • Dashboard with the information and next actions your roles allow
  • Personnel directory with profiles, custom fields, bulk edit, disabling, and deletion controls
  • Certification Hub with types, categories, and expiry reminders
  • Roles with templates, cloning, colors, and action-level permissions that combine across a member’s roles
  • Dept Communications: announcements with priority, audiences, scheduling, pinning, and acknowledgement tracking
  • Department email to named members or whole roles — immediately, at a scheduled time, or repeating daily, weekly, or monthly — with email logs
  • Department calendar with month, week, and phone views, recurring events, categories, RSVP, reminders, and a personal .ics feed
  • Workflows: triggers, actions, approvals, signed incoming webhooks, templates, run history, and simulated test runs
  • Authenticator-app or email 2FA with backup codes, and a logged “view as member” mode for authorized admins
  • Activity log with actor, target, and severity; critical entries are kept permanently
  • Optional Sparky AI assistant (off until enabled) and the Support Hub

Use the module hub to open the dedicated procedure associated with any capability listed here.

Connected modules and downstream effects

A change here can alter what members see, what data appears in reports, or how another module completes its workflow. Review the connected areas below before making a department-wide change.

  • Time ClockPortal and kiosk clock-in with password, PIN, or face, plus corrections and reports.
  • SchedulingAvailability, rotations, schedule building, trades, time off, and callouts.
  • TrainingEvents, attendance, hours and CE, certificates, self-logged training, and compliance.
  • ResourcesVersioned documents with acknowledgement and signature tracking (formerly Policies).
  • ChatRole-controlled department channels with replies, reactions, files, and push.
  • RecruitingApplication Hubs, reviews, interviews, references, and conversion (formerly Applications Flow).

After deployment, test one complete workflow from the originating module through every connected destination your department uses. Document the final configuration so another administrator can audit or reproduce it later.

Continue in Core

Return to the Core module guide for connected workflows, dependencies, portal destinations, and additional procedures.

Was this article helpful?

Your feedback helps us make these guides more useful.

Related guides