Use custom fields in workflows without confusing conditions and events

Updated Wednesday, October 28, 2026 · Marcel Gravelle

Custom fields turn important support facts into structured values that a workflow can evaluate. A maintained service tier, environment or investigation category can be more dependable than guessing intent from a subject line. The field value is a condition; an event such as Created or Updated determines when the workflow evaluates it. Keeping these two ideas separate makes automated routing easier to reason about and troubleshoot.

At a glance

For: support operations administrators managing structured case information and workflows. Applies to: Supportbench Core.

Start here: Settings → Configuration → Workflows

Choose a field that represents a reliable support fact · Understand the condition groups · Configure the event and custom-field rule · Plan for repeated Updated events · Test the complete field-driven decision · Example: structured equipment support routing · Troubleshoot field-based automation

Choose a field that represents a reliable support fact

Begin with the decision the team wants to make. For example, an equipment supplier may want production-environment cases for a particular supported service to receive a specialist review. Agree who maintains the field and what each value means before using it to change ownership or notify people.

Use an existing appropriate field rather than creating another field with nearly the same meaning.
Confirm the field is available on the intended case or entity scope and that the right people can maintain it.
Decide how blank, unknown and not-applicable values should be handled. Do not silently treat an unknown value as a verified low-risk condition.
Select the field, then use the type-specific value control shown. Comparison behavior depends on field type; there is no universal operator menu.
Identify the action and a test case whose expected result is known.

A field should record evidence, not manufacture it. A selected “Production” environment is useful when someone confirmed the affected environment. A rule that selects “Production” merely because a customer sounds frustrated can make reports and routing less trustworthy.

Understand the condition groups

Group or control	How to use it
Trigger	Choose the record scope and the event that starts evaluation. A field value is not a standalone trigger.
Requirements	All configured requirement rules must pass. Use this for facts that must always be true for the action.
Conditionals	An at-least-one matching group. Review it together with existing conditionals so a broad alternative does not weaken your intended restriction.
Exclusions	A matching exclusion prevents the rule from applying. Use this for a clearly defined exception.
Custom fields / Add custom field	Add a supported field rule, such as Case field — {name}, in the appropriate condition or action location.

Keep the meaning of each row explicit. “Environment is Production AND Service is Equipment” is a different rule from “Environment is Production OR Service is Equipment.” Review the displayed groups with someone who understands the support process, not only the person entering the values.

Configure the event and custom-field rule

Open Settings → Configuration → Workflows with workflow administration permission. Create or open the intended rule.
In Details, give it a purpose-based name and review its active state and priority.
On Trigger, choose the correct record scope and an event that occurs in your intended path, such as Created or Updated.
Open the intended Requirements, Conditionals or Exclusions group. Under Custom fields, use Add custom field and select the supported field entry, for example Case field — {name}.
Enter or select the type-specific Option value, Content or Date value control shown. The field type determines comparison behavior and the condition group determines how rules combine. Check that the field belongs to the intended scope; a similarly named Company field is not automatically a Case field.
Configure the intended supported action in Actions. If that action changes a field, review whether it can cause another evaluation or match another rule.
Review processing priority and Stop processing, save the configuration, and reopen it to confirm the stored field, group and value.

The builder requires a field selection for each custom rule and only allows supported field locations for the chosen scope. Read validation rather than switching to an unrelated field just to save. Keep a rule understandable; a long set of loosely related alternatives is hard to test and maintain.

Plan for repeated Updated events

A saved custom-field change can invoke an Updated workflow. If a matching workflow then changes a field, another event may follow. Design the conditions so the desired final state does not repeatedly request the same change.

Stop processing is not a loop-prevention guarantee

Stop processing ends the remaining lower-priority workflows in the current matching pass. It does not suppress a later, separately invoked event produced by an update. Use narrow event/condition design and test repeated updates.

For example, a rule whose sole condition is “Service tier is Priority” can still match after an unrelated field is edited. Add only supported conditions that accurately distinguish the intended situation. Do not assume that choosing Updated means “this one field changed from the old value to the new value” unless the selected condition explicitly supports and tests that behavior.

Test the complete field-driven decision

Test	Expected review
Matching field value on the intended event	The configured action occurs and the final owner/queue/field values are correct.
Nonmatching or blank value	The rule does not silently treat the missing fact as a match.
Matching value with an exclusion	The exception is honored.
Unrelated field edited afterward	Check whether Updated reevaluates the rule and whether the result is still appropriate.
Action changes a field	Look for another event, duplicate notification or repeated routing.
Another workflow matches	Inspect the final state after processing, not just an intermediate change.

Use approved training records and recipients. A successful configuration save does not simulate the workflow. Record the event, input values, observed action and final case state so another administrator can reproduce the decision.

Example: structured equipment support routing

A manufacturer’s case has an agreed Environment field and an affected Asset. The agent confirms that the problem affects a production installation before selecting the value. A narrow workflow combines the supported environment condition with the intended service/customer scope and routes the case for specialist attention.

The specialist still receives a complete handoff: symptoms, impact, attempted work and next update time. The custom field makes the routing criterion visible and reportable; it does not replace the investigation. During weekly review, sample both routed cases and near misses to see whether the field definitions and workflow still fit real support work.

Troubleshoot field-based automation

Symptom	Correction
The field is absent	Check scope, field availability and the field type/location supported by the builder.
The rule never fires	Verify the actual event, all requirements, conditional groups, exclusions and active state.
The rule fires for too many cases	Review AND versus OR placement and blank-value handling.
The same notification repeats	Inspect Updated events and actions that write fields; narrow the conditions rather than relying only on Stop processing.
The wrong field changed	Compare similarly named Case, Company and Contact fields and the chosen action scope.

Was this article helpful?