Build an activity-keyword workflow that recognizes the right support situation

An activity-keyword workflow can notice a meaningful phrase in a support activity and apply your configured response. This is useful when an incoming update should draw attention to a particular service, incident or request. The important decision is not simply which word to match: it is which event, customer context and action make that word operationally useful. A broad word such as “error” can match many unrelated cases, including a sentence that says no error occurred.

Describe the situation before building the rule  ·  Separate the event from the condition  ·  Configure the focused workflow  ·  Example: use a sender-domain requirement for a new email-created Case  ·  Test positive, negative and update cases  ·  Example: route a recurring integration symptom  ·  Troubleshoot missed and unexpected matches

Describe the situation before building the rule

Write one sentence describing the intended result: “When a new eligible customer activity reports the exact integration failure phrase, bring the case to the integration team’s attention.” Identify the customer population, event, phrase, intended action and exclusions. Treat the phrase as a signal that needs context, not proof that the customer has a particular root cause.

For a B2B organization, similar words may mean different things to different customers. A “production stop” message from a contracted equipment operator may need different handling from a test-environment question. Combine text with supported customer, case or service conditions when those conditions are available. Keep a human review step where the action depends on interpretation rather than a reliably recorded fact.

• Use a distinct phrase or agreed operational marker when possible.
• List examples that should match and similar examples that must not match.
• Choose the minimum action that helps the team: an appropriate configured notification or routing action, rather than several unrelated changes.
• Identify the workflow owner and the team that will investigate an unexpected match.

Separate the event from the condition

Activity Text is a condition. It is not an event called “Content Contains.” The matcher inspects the activity content associated with the event. Do not assume a rule automatically searches every earlier activity in a case, or that a Created rule will run when someone edits an existing activity. Select the event deliberately and test that specific activity path. Text matching is case-insensitive substring matching, not semantic interpretation: “no error occurred” can still contain “error,” and a short term can appear inside a longer word. A comma separates terms; it does not create an exact-sentence comparison.

Configure the focused workflow

1. Open Settings → Configuration → Workflows with permission to administer workflows. Open the intended existing rule or create a new one.
2. In Details, give the rule a name that describes the business result and review its active state and processing priority. Record the purpose in the available description.
3. On Trigger, select the correct record scope and event. Confirm that the event corresponds to the action that will produce the activity you want to inspect.
4. Open Requirements or Conditionals, add Activity Text or Activity Text (Any), and enter the intended phrase or comma-separated terms. Activity Text requires every nonempty term; Activity Text (Any) requires at least one. Both use case-insensitive substring matching. Requirements combine the configured conditions with AND; Conditionals provide an at-least-one condition group.
5. Add supported scope restrictions and exclusions needed for your situation. Review the entire rule so that a broad alternative condition cannot unintentionally bypass the customer context you intended.
6. In Actions, configure the intended supported action and destination. Check the order of multiple actions and their effect on ownership, priority, recipients or other fields.
7. Review priority and Stop processing alongside other rules for the same event. Save through the editor’s save action, reopen the rule and confirm its stored settings.

A workflow save confirms configuration, not the correctness of every incoming message. Perform the controlled checks below before treating the rule as part of a customer commitment. Where your environment lacks a separate test tenant, use an approved training case and recipients; a matching rule can execute real actions.

Example: use a sender-domain requirement for a new email-created Case

Use this example only after an inbound Email Route and its forwarding have been tested. Email ingestion creates the Case and initial Activity; the workflow then evaluates the selected event. A domain value is a condition, not an email-ingestion trigger or proof of the sender’s identity.

1. Open Settings → Configuration → Workflows and create or open a narrowly scoped rule with an accountable owner. In Trigger, choose scope Case and event Created for this new-case example.
2. Under Requirements, add From Domains. Enter the intended sender domain, such as northstar.example. Comma-separated values are alternatives within this field; matching uses the triggering Activity’s sender domain and exact case-insensitive comparison. A subdomain is a separate value, not an implied wildcard match.
3. If you also require a symptom phrase, add the appropriate Activity Text requirement. Domain AND phrase is different from domain OR phrase. From Domains is not offered in Conditionals. A true domain-or-keyword design needs separately reviewed workflows, with overlap and action ordering tested.
4. Use From Domains Not under Exclusions for an intended excluded sender domain. Review the complete rule, including every other requirement, conditional, exclusion and action.
5. Choose the minimum supported routing or notification action needed. Check priority and Stop processing with other rules. Save and reopen the rule to confirm its settings.
6. Create a brand-new test email from the intended domain to the verified inbound route so that it creates a new Case with its initial email Activity. Confirm the actual sender, new Case identity and final action.
7. Repeat with another domain, a different phrase, a subdomain and a reply to an existing Case. A reply follows the update path; it does not establish that the Case Created rule ran.
8. Test other Case-creation paths used by your account before activation. If a path invokes Case Created without an Activity, the sender conditions are skipped; a domain requirement alone does not safely restrict that invocation. Keep the rule out of use until its scope and consequences have been verified for those paths.

There is no supported attachment-presence condition in this current Case workflow field set. Do not carry an old “has attachment” routing recipe into the rule or substitute a keyword as proof that a file exists. Use the full condition reference to choose actual supported fields, and preserve a manual review step where the required signal is unavailable.

Test positive, negative and update cases

Keep the test activity and the observed outcome in your operational change record. Check the case history, final assignment and relevant configured diagnostics. The workflow editor’s Audit tab records configuration information; timestamps there alone do not prove that a particular customer activity executed the rule.

Example: route a recurring integration symptom

An account team receives reports from several contacts at a manufacturer. The phrase “ERP export rejected” identifies a known integration symptom, but the same company also sends unrelated installation questions. Build the rule around the relevant activity event and the agreed phrase, with supported scope conditions for the intended service. Choose the team action your operating model requires.

Test the exact phrase, a similar nonmatching phrase, a reply that quotes an earlier failure, and a message from another customer. If the rule routes the quoted reply unexpectedly, refine the operational approach rather than adding a more destructive action. The benefit is consistent first attention; the specialist still confirms the cause, customer impact and next update commitment.

Troubleshoot missed and unexpected matches

Continue learning

• Configure workflow structure and processing
• Review available workflow conditions
• Review available workflow actions
• Use an explicit hashtag event
• Use custom-field conditions
• Understand the inbound email path