Workflow, Flow Designer, and Approvals
Automation comes in two flavors: legacy Workflow (graphical, activity-based, stored in wf_workflow) and Flow Designer (trigger-based, action/subflow model). Candidates must understand triggers (record created/updated, scheduled, etc.), actions (reusable steps), subflows, and flow logic (if, for each, do until). Approvals can be generated by workflows, flows, or the Approval table (sysapproval_approver).
Know the approval states (requested, approved, rejected, cancelled) and how approval rules route to users or groups. Business rules can trigger approvals; flows often use the Ask for Approval action. Understand SLA definitions as a related concept (timers on task records).
Traps: assuming Flow Designer and Workflow are interchangeable (they are separate engines; flows are preferred going forward). Assuming an approval automatically advances the record - you must configure the flow/workflow to act on the approval result. And confusing approval rules (routing) with approval records (instances). Another trap: assuming a flow trigger fires on every field change - triggers have conditions.
Worked example: To require manager approval on a catalog request, create a flow triggered on sc_req_item creation, add an Ask for Approval action routed to the requester's manager, then branch on the approval result: if approved, move the item to fulfillment; if rejected, set state to Closed Incomplete and notify the requester.