7.7 Automation Case Lab

Lab scenario: premium support triage

Use a sandbox, Developer Edition org, or Trailhead Playground for this practice. The business scenario is a service team that supports standard and premium customers. New premium cases should route to a Premium Support queue. Sev 1 cases should notify a support manager and create an urgent follow-up task. Cases cannot move to Working until Product Family is populated. Cases that remain New for four business hours should escalate to the manager queue. The team wants a simple guided action for agents to classify a case and capture the first response.

This scenario is intentionally mixed. It should not become one enormous flow. Case assignment rules are a natural fit for initial queue routing. A validation rule is a natural fit for blocking status movement without Product Family. A case escalation rule can handle aged New cases if the requirement matches standard escalation behavior. A screen flow can guide agents through classification and first response. A record-triggered flow can create the urgent task and notification for Sev 1 cases if assignment and escalation rules do not cover that action cleanly.

Start by writing the process in plain language. New cases arrive from Email-to-Case, web forms, and manual creation. Premium status is stored on Account or on a case field copied from Account. Severity is a case picklist. Product Family is required before work begins. Agents work from queues. Managers need alerts for urgent cases but should not receive duplicate messages every time a case is edited. These statements become your design constraints.

The lab is successful when you can explain why each tool is used. If you choose Flow for everything, you miss the purpose-built features. If you avoid Flow entirely, the guided agent experience and task creation may be clumsy. The admin skill is balanced selection.

Build plan and setup checklist

Setup checklist:

1. Create or confirm a Premium Support queue for cases and add test members.
2. Create a support manager test user or identify a safe existing test user in the sandbox.
3. Confirm Case fields for Severity, Product Family, Account, Status, and any Premium indicator.
4. Build a case assignment rule entry that routes premium cases to the queue.
5. Build a validation rule that blocks Status equals Working when Product Family is blank.
6. Configure escalation behavior for New cases that exceed the business-hour threshold.
7. Build a screen flow that lets an agent classify Product Family, enter first response notes, and move Status to Working.
8. Build a record-triggered flow for Sev 1 task and notification behavior with criteria that prevent duplicates.

The Sev 1 flow needs careful design. It should run when a case is created or updated to meet Severity equals Sev 1 and perhaps when Urgent Task Created is false. It should create one task assigned to the right owner or queue and set a flag to prevent re-creation. If that flag update is on the same record, consider whether before-save or after-save timing fits the whole design. Because task creation requires an after-save action, you may use after-save flow but must prevent recursion with criteria and a flag.

Test script, release notes, and study judgment

Run the lab with at least five records. Create a standard case and confirm it does not route to Premium Support. Create a premium case and confirm assignment. Create a premium Sev 1 case and confirm the urgent task and notification are created once. Try to move a case to Working without Product Family and confirm the validation message is clear. Use the screen flow to classify the case and confirm the status update succeeds. Create a case that should escalate and test the rule timing in the safest available way for the environment.

Test as different users. The system administrator can usually do everything, but agents and managers may have narrower permissions. Confirm queue members can see and accept cases. Confirm the manager can open the notified record. Confirm the screen flow is available from the Lightning page or action where agents expect it. Confirm field-level security allows users to read and edit fields the flow displays. A flow screen that shows a field the user cannot use is a design bug, not just a permission bug.

Bulk and failure tests matter. Import or update a small set of cases to simulate channel volume. Confirm the assignment rule behavior for the entry point you choose. Confirm the Sev 1 flow does not create duplicate tasks when records are edited again. Force a validation failure by leaving Product Family blank. Try a locked or closed case if that state exists in the org. Review failed flow interviews, task lists, queues, and notification volume after testing.

Lab documentation template:

• Business purpose: premium support triage and urgent response.
• Tools used: case assignment rule, validation rule, escalation rule, screen flow, record-triggered flow, notification action.
• Objects touched: Case, Task, Account if premium status is read, User or Queue for ownership.
• Entry criteria: premium indicator, Severity equals Sev 1, Status equals New, Status changes to Working.
• Bypass or exception: documented admin-only data repair path if needed.
• Monitoring: queue reports, aged case report, urgent task report, failed flow interviews, manager feedback.

For study purposes, focus on the reasoning. A scenario that says route cases should point you toward assignment rules before custom flow. A scenario that says block save should point to validation. A scenario that says guide an agent should point to screen flow. A scenario that says approval, lock, and approve should point to approval process. The case lab trains you to combine features while keeping each feature in its strongest lane.