10.5 Flow Automation and Change Control Integrated Lab

Lab scenario: automate a customer handoff

A company wants a consistent handoff when an opportunity is marked Closed Won. The sales rep should confirm implementation details, a customer onboarding case should be created, the account should be flagged as a customer, and the account owner should receive a task for the kickoff call. The admin must decide what belongs in automation, what belongs in user confirmation, and how to release the change without disrupting current sales work.

Start with process discovery. Ask what event starts the process, who owns the result, which records are created or updated, what fields are required, what exceptions exist, and what reports should change. In this lab, the event is an Opportunity stage change to Closed Won. The handoff case needs Account, Contact, Priority, Product Area, and Description. The account update sets Customer Status to Active Customer. The task reminds the owner to schedule a kickoff call. Exceptions might include renewals, internal test deals, partner-led implementations, or opportunities without a primary contact.

Choose the design. One option is a record-triggered flow on Opportunity that runs when Stage changes to Closed Won and required fields are present. It creates a Case, updates the Account, and creates a Task. A second option is a screen flow launched from an action, where the rep confirms onboarding details and the flow performs the handoff. The screen flow gives better user confirmation, while the record-triggered flow is more automatic. For this lab, build a record-triggered flow with strict entry criteria and a validation rule that prevents Closed Won when core handoff fields are missing.

Build in a sandbox or Trailhead Playground. Go to Setup > Flows, create a record-triggered flow on Opportunity, and trigger it when a record is updated. Entry criteria should include Stage equals Closed Won and a condition that detects the relevant change so the flow does not create duplicate cases on every later edit. Use Get Records to find related data only if needed. Use Create Records for the onboarding Case and Task. Use Update Records for the Account. Label every element clearly. Add a description explaining the business owner and release date.

Expected observations in a successful test: when a valid opportunity moves from Negotiation to Closed Won, one onboarding case is created, one kickoff task is created, the account customer status changes, and reports can identify the new case. When the opportunity is edited later without changing stage, no duplicate case appears. When required handoff fields are missing, the validation rule blocks the stage change with a clear message. When a user lacks access to a field or object, the flow behavior should be understood and documented based on how the flow runs.

Test failure modes deliberately. Try closing an opportunity without a primary contact. Try a bulk update of several opportunities. Try an opportunity linked to an account that is already an active customer. Try a user who can close opportunities but cannot create cases if your design depends on user context. Try a duplicate stage update. Try a Data Loader update. Try a deactivated owner or missing queue. A lab that only proves the happy path is not enough for administrator readiness. Automation failures usually appear at boundaries.

Think about order of execution and side effects. Validation rules, duplicate rules, flows, assignment rules, escalation rules, and other automation can interact. Creating a case may trigger case assignment rules or additional flows. Updating an account may trigger account automation. Sending notifications may surprise users if test data looks real. Use debug tools and Flow error emails, but do not rely on error emails as the support process. Create a place to record automation owner, purpose, entry criteria, fields touched, related objects, expected volume, and emergency deactivation steps.

Move through change control. Document the requirement, configuration changes, test cases, user acceptance evidence, deployment components, activation timing, and communication plan. Use change sets, DevOps Center, source-driven deployment, or the repo's approved method depending on the org. Deploy inactive where possible, then activate during the release window after dependencies are present. Confirm profiles, permission sets, fields, validation rules, record-triggered flow activation, and report changes all moved. After release, monitor Flow error emails, sample records, dashboards, and user feedback.

Review prompts before the quiz:

• Why might a screen flow be better than a record-triggered flow for some handoffs?
• How would you prevent duplicate onboarding cases after later opportunity edits?
• Which bulk and permission tests should be included before activation?
• What release evidence would you keep for the change advisory record?
• What is your emergency plan if the flow blocks revenue operations after release?