Workflows

Optional · Automate useful work

A workflow automates a repeatable decision. Its trigger says when to evaluate, its conditions identify matching records, and its actions do the work. Begin with one narrow rule whose outcome you can check.

Before you begin

Use an administrator with workflow permission. Have the destination queue and any required classifications ready. Review existing rules for the same record type and event. Workflow actions can change records, send messages or call external systems.

Northstar’s example rule is: “When a case is created in Customer Support with the report-export issue, place it in the monitored Support Queue.” This is an example; if the incoming channel already routes every relevant case correctly, another rule may be unnecessary.

Build the rule while inactive

1. Open Settings → Configuration → Workflows.
2. Search for related rules before creating a new one.
3. Select New workflow. In Details, enter a meaningful Name and Description explaining the purpose.
4. Choose What: Case and When: Created for the example. Set these before adding conditions, because changing them can invalidate existing selections.
5. Review Order and Stop When Hit. A matching rule with Stop When Hit prevents lower-priority rules for that scope/event from running.
6. Turn Active off while preparing the rule. New workflows can start active; inspect the actual switch before the first save.

Saved Northstar routing workflow with Active off while its behavior awaits controlled execution tests.

Add conditions and actions

1. Open Requirements. Use Add a requirement to add Issue, then choose Report export. Add Category, then choose Customer Support. In this workflow picker, Category contains the division choices. All requirements must match.
2. Use Conditionals only when you need an appropriate at-least-one alternative group.
3. Review the available tabs and each condition’s explanation. Tabs vary by event; the Created example has Requirements and Conditionals. If an exception is needed, choose a supported condition/operator that expresses it and test the excluded case.
4. Under Actions, select the Assign queue action and the intended monitored queue.
5. Do not add notifications or external calls to a routing exercise unless they are part of the agreed behavior.
6. Save, resolve validation messages and reopen the rule. Confirm the selected record type, event, conditions, destination, order and inactive state.

Saved requirements: Issue is Report export and Category is Customer Support. Both must match.

Saved inactive training workflow assigns matching cases to Support Queue without sending messages.

Workflow triggers, conditions and actions is the complete configuration reference. Available actions depend on scope, event and enabled capabilities.

Test matching and nonmatching cases

1. In the controlled test environment, activate the reviewed rule and save.
2. Create the Harbor report-export case with the intended matching classification, using an internal activity if no delivery test is intended.
3. Inspect the saved case’s queue, owner and history. Check its final state after other processing, not just the first screen response.
4. Create a harmless nonmatching case with another issue. Confirm the rule does not route it incorrectly.
5. Review nearby rules for overlapping conditions and Stop When Hit behavior.
6. If the result differs, make the rule inactive while correcting it, then repeat only the affected checks.

A saved configuration does not prove execution. A matching rule does not prove a message reached a recipient. Verify each action’s actual result.

Avoid common mistakes

Use exact structured conditions where possible. A broad subject substring can match more cases than intended. Do not use a workflow to compensate for an unclear issue taxonomy or unmonitored queue.

Limit run times controls when evaluation may run; it is separate from an SLA’s business-hours clock. Scheduled workflows also have their own timing rules. Leave these unused for the initial Created example unless needed.

If a rule does not fire, inspect Active, What/When, all requirements, alternatives and order. If routing changes again, inspect later workflows and the channel’s behavior. If a notification is missing, inspect its recipient choice and delivery separately.

Completion check

• The rule can be explained in one sentence.
• Scope, event and conditions are precise.
• Matching and nonmatching tests pass.
• Final queue/owner and history agree with the intent.
• Unneeded automation remains deferred.

Previous: Customer Roles and Knowledge Access · Next: Enabling Escalations