Build, test, and publish a workflow

Understand the outcome

Workflows run department processes on their own. Test runs simulate every effect, so you can check a workflow before it touches real records.

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.

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.

• Write down the process in plain steps.
• Identify where a person should approve before the workflow continues.
• Make sure you hold the permissions for the actions the workflow will take.

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 Workflows

   Go to Settings → Workflows and start from a template or a blank workflow.

2. Step 2Choose a trigger

   Select the event that starts the workflow, or a signed incoming webhook.

3. Step 3Add actions

   Add each step. Steps that change records are checked against your permissions when you save.

4. Step 4Add approvals

   Insert an approval step where a person must confirm.

5. Step 5Run a test

   Start a test run; nothing is sent, written, or called. Review the simulated results.

6. Step 6Publish and monitor

   Publish, then watch Runs and Approvals.

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 test run shows the expected steps.
• The first real run appears in Runs.
• Approval steps appear for the right people.

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

Save is refused for a step

You don’t hold the permission for that action. Ask an administrator or remove the step.

The workflow never runs

Confirm it is published and the trigger event actually happened.

A run is stuck

Check Approvals for a step waiting on someone.

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.