Design, test and maintain workflows for dependable B2B support

A workflow applies configured actions when a supported event occurs and the record matches its rules. Use workflows to make a clear operating policy repeatable: route the right cases, apply a maintained priority rule or coordinate a defined escalation handoff. In B2B support, the useful automation preserves customer context and responsibility across teams. It should make a decision your team understands, with evidence that it acts on the intended records and leaves other work alone.

Start with a decision that can be explained  ·  Prepare access and a controlled validation plan  ·  Understand the workflow parts  ·  Combine Requirements, Conditionals and exclusions correctly  ·  Build and save an inactive workflow  ·  Understand execution order and action interactions  ·  Worked example: classify a specific server issue  ·  Worked example: route an escalation without losing responsibility  ·  Verify the outcome with a small test matrix  ·  Change, pause and retire workflows deliberately  ·  Troubleshoot a workflow one layer at a time

Start with a decision that can be explained

Do not begin by asking which actions can be added. Write the intended decision first: “When this event occurs, for these records, unless this exception applies, take this action.” A workflow is a configured process, not a guarantee that every case reaches the right team or every customer commitment is met.

Prepare access and a controlled validation plan

1. Confirm permission to Manage system workflows and write access to the Workflows section. Opening the configuration page alone does not prove you may save changes.
2. Identify the process owner and the people affected by the action. Review current workflows in the same scope/event before adding another.
3. Write the intended scope, event, matching criteria, exceptions, action and execution-order dependency. Record a positive example that should match and a negative example that must not.
4. Prepare a controlled account or preapproved representative records for validation. Any test that triggers real routing, messages or integrations has those effects; there is no harmless editor simulation implied by Save changes.
5. Identify the rollback step: normally deactivate the new rule and save, then review any records already changed. Disabling a rule prevents future applicable executions; it does not undo earlier actions.

Understand the workflow parts

An event and a condition are different. A case acquiring a field value does not imply that a rule listening to a different event will be evaluated. Select the actual scope/event in Trigger, then use the available field choices for that combination. Changing scope or event can remove incompatible rules or actions after confirmation; read that warning and recheck the entire definition.

Combine Requirements, Conditionals and exclusions correctly

Think of Requirements as AND: all configured entries must be true. Conditionals provide OR: at least one must be true when you use that section. A matching exclusion vetoes the workflow. Empty Requirements do not add a hidden safety condition, and Conditionals are optional; a sparse rule can therefore match more broadly than its name suggests.

These are logic examples, not a promise that every field is available in every scope/event. Use the actual fields exposed by the editor and the field references. Avoid ambiguous keyword shortcuts for business-critical routing. An exact maintained field is usually easier to explain than a broad word that can also appear in an unrelated email signature or quoted history.

Build and save an inactive workflow

1. Open Settings → Configuration → Workflows, then choose New workflow, or use the supported Copy action on a closely related rule.
2. On Details, enter a descriptive Name and Description. Include the intended result, process owner and meaningful exception. Set Active off while preparing.
3. Set Order deliberately in the context of existing rules. Review Stop When Hit separately; leave it off unless stopping subsequent rules in this event pass is required and tested.
4. Open Trigger and choose the intended scope and event from the offered choices. Do not keep the default Case/Created combination unless it matches the operating policy.
5. Open Requirements and add the must-match fields. Add Conditionals only for genuine alternatives. Review the available exclusions for deliberate exceptions.
6. Open Actions and select the smallest set that produces the intended outcome. Choose valid current target values, such as the intended priority or queue.
7. Review the whole rule, including any changed scope/event warnings, then choose Save changes. Resolve validation errors without broadening access or removing important constraints merely to save.
8. Reopen the rule and verify its saved values and inactive state. A successful save confirms a stored definition; it does not prove that its event has occurred or its actions have executed.

Understand execution order and action interactions

The Workflows interface describes higher-priority rules as running first. Use the displayed ordering and test the actual intended sequence; do not assume that a larger entered number means earlier execution. The underlying order is ascending, with further tie-breaking, so ambiguous equal-priority rules are a poor basis for a critical process.

Stop When Hit stops the remaining lower-priority rules in the same scope/event evaluation pass after a match. It does not permanently protect the case from later events or unrelated workflows. Another event triggered by a change can start a separate evaluation.

Review actions in their displayed top-to-bottom sequence. Each action type can be selected only once in a workflow. If the process needs multiple different effects, confirm that the available action combination actually expresses them; do not assume duplicating a field in the editor creates repeated actions. Some actions can cause subsequent events, so inspect interactions with other rules.

Worked example: classify a specific server issue

Suppose the team has agreed that new cases classified with a particular maintained Server issue need a specific priority. This is a recommendation example, not a default Supportbench policy. Confirm the exact issue and priority labels in your account before using it.

1. Write the policy and exceptions. For example, identify the intended Division/customer scope and whether planned requests or test records should be excluded. Do not equate every message containing the word “server” with this issue classification.
2. Create an inactive Case workflow and choose Created when the intent is classification at creation. Confirm that the issue value will exist at that point in the actual intake path.
3. Add a Requirement selecting the intended Issue and any additional must-match scope. Add supported exclusions for the agreed exceptions.
4. Add Update priority and select the agreed priority. Avoid unrelated assignment, email or integration actions in this first rule.
5. Save, reopen and compare the definition with the written policy. Review other creation and update rules that could also affect priority.
6. An inactive rule does not execute. Enable it only in an isolated test account or an explicitly approved, controlled live test, then validate a matching case and a nonmatching case. The matching case should receive the intended priority; the nonmatching one should retain the expected value. Check the saved case and history, not just a workflow success message.
7. Test the actual intake path used by the team. If classification is supplied later, use the supported event that fits that timing or revise the process; do not expect an earlier creation event to rerun automatically.
8. Activate in the approved operational scope only after review, then monitor representative new results and exceptions.

Worked example: route an escalation without losing responsibility

The useful part of an escalation workflow is a dependable handoff. Automatically assigning a queue does not prove that someone accepted the work, can access it or knows the next customer update time.

1. Agree the receiving escalation queue, the responsible roles and who retains customer communication. Verify access to the intended cases and the team’s coverage.
2. Create an inactive workflow for the supported Case Escalated event. Add Requirements that identify the intended escalation process and scope; avoid a broad rule that captures every unrelated escalation.
3. Choose Assign queue and the agreed target. Review whether other actions or later workflows change ownership, queue or priority.
4. Save and inspect the rule. An inactive rule does not execute. Enable it only in an isolated test account or an explicitly approved, controlled live test, then validate a representative escalation and a negative case. Verify the final assignment, case visibility and the receiving team’s understanding.
5. Document the escalation evidence, next action and customer update commitment on the case. Use the focused escalation guide for escalation and de-escalation behavior.
6. Activate through the team’s change process and review the first operational results. Investigate a handoff failure as both a routing issue and an ownership/communication issue.

Verify the outcome with a small test matrix

Keep the case IDs, event timing, expected result and observed result in your controlled change record. Use approved test data and audiences. The editor does not provide a general Test Run simulation; Save changes validates configuration and persists it. Do not generate customer messages as an unreviewed experiment.

Change, pause and retire workflows deliberately

1. Identify the rule’s owner and read its Description, current values and Audit information. Review affected callers/events and related workflows before changing it.
2. Prefer a narrowly scoped edit or an inactive copy for a substantial redesign. A copy does not include proof of the original’s runtime behavior.
3. Save the reviewed definition and reopen it to verify. Repeat the relevant positive, negative and interaction checks when criteria or actions change.
4. To pause future use, turn Active off and save. Confirm the inactive state and review any work that was already changed.
5. Use deletion only when that retirement is intended. Deleting/deactivating configuration does not roll back earlier case changes, delivered messages or external operations.
6. When customer processes, labels, routing or permissions change, update the rule’s explanation, operating instructions and test evidence together. Recheck affected knowledge articles.

Troubleshoot a workflow one layer at a time

Continue learning

• Configure workflow settings
• Workflow field reference: triggers and conditions
• Workflow field reference: actions and exclusions
• Manage escalation and de-escalation
• Use keyword rules deliberately
• Choose and operate the appropriate webhook