Service Omni Routing Flow Deploy

service-omni-routing-flow-deploy

Voice runtime proof depends on a provisioned Contact Center. Flow redeploys report Changed even when the deployed configuration is unchanged.

Deploy an Omni-Channel routing Flow via the Metadata API, confirm it lands Active, and prove it routes work — either by CLI invocation (the autolaunched dry-run) or by observing real routing side effects (the record-triggered variant). service-omni-channel-setup-coordinate wires it in after service-omni-queue-deploy has produced the target queue and its members are bound.

Variants

Four assets ship under assets/force-app/main/default/flows/ — an autolaunched and a record-triggered variant for each of Case and VoiceCall. Selection is by --target Case|VoiceCall (default Case) and --trigger.

The autolaunched variant de-risks the headless CLI path cheaply; the record-triggered variant proves real records reach a queue. A full steel thread deploys the record-triggered variant.

With --trigger --routing-type SkillsBased, the record-triggered variant is drawn from a sibling <FlowDN>.SkillsBased.flow-meta.xml asset that emits routingType=SkillsBased plus a non-null skillOption. The base trigger flows hardcode routingType=QueueBased, so a skills-based-routing org config never takes effect at runtime — this variant is what makes it route by skill (W-24069467).

Inputs

bash scripts/deploy-and-report.sh <org-alias> [flow_developer_name] [--target Case|VoiceCall] [--trigger] [--routing-type QueueBased|SkillsBased] [--skill-option RunSBRRules|DefineSkillRequirements|Both] [--runtime-proof] [--require-proof] [--skip-invoke]
# autolaunched smoke test (Case):
bash scripts/deploy-and-report.sh myorg
# record-triggered Voice routing with runtime proof:
bash scripts/deploy-and-report.sh myorg --target VoiceCall --trigger --runtime-proof
# skills-based Case routing (platform evaluates WorkSkillRouting rules):
bash scripts/deploy-and-report.sh myorg --target Case --trigger --routing-type SkillsBased --runtime-proof

• --target Case|VoiceCall (default Case) — selects the flow pair.
• --trigger — deploy the record-triggered variant with dynamic token resolution.
• --routing-type QueueBased|SkillsBased (default QueueBased; env OMNI_ROUTING_TYPE) — SkillsBased deploys the <FlowDN>.SkillsBased variant that calls routeWork with routingType=SkillsBased, so the org's skills-based routing config takes effect at runtime instead of being inert. It deploys under the same DeveloperName, replacing the QueueBased trigger (never two triggers on one object).
• --skill-option RunSBRRules|DefineSkillRequirements|Both (default RunSBRRules; env OMNI_SKILL_OPTION; SkillsBased only) — RunSBRRules/Both make the platform evaluate the org's WorkSkillRouting rules server-side and attach matching SkillRequirement rows to the PSR; DefineSkillRequirements uses only skills the flow itself passes. A SkillsBased deploy with an empty/invalid skillOption is refused (exit 2): a null skillOption NPEs the platform routeWork action and rolls back the triggering insert (W-24069761), so the asset always carries a non-null value.
• --runtime-proof (implies --trigger) — after deploy, insert a target record. QueueBased accepts a PendingServiceRouting or AgentWork row. SkillsBased requires a PendingServiceRouting with at least one SkillRequirement, proving that RunSBRRules evaluated the active WorkSkillRouting rule. Proof is fail-soft unless required. The record is always deleted afterward.
• --require-proof (implies --runtime-proof; also OMNI_RUNTIME_PROOF_REQUIRED=1) — makes that proof blocking; the release gate for the Voice steel thread.
• --skip-invoke (autolaunched only) — deploy + verify Active, no Actions REST call.
• Token overrides (--trigger): QUEUE_DEVELOPER_NAME, ROUTING_CONFIG_DEVELOPER_NAME, SERVICE_CHANNEL_DEVELOPER_NAME. The coordinator always supplies these three from the resources it established for the target, so the flow binds the same channel/queue/QRC rather than a guessed default.

Preconditions and safety

• Target org authenticated via sf CLI, Service Cloud license, sf CLI ≥ 2.139.6, jq ≥ 1.6.
• Omni-Channel base settings enabled (service-omni-base-settings-configure) — the routing action resolves only when Omni is on; the flow deploys without it but fails at runtime.
• Record-triggered runs need a deployed ServiceChannel (service-omni-service-channel-configure), Queue (service-omni-queue-deploy), and QueueRoutingConfig (service-omni-queue-routing-config-deploy) to resolve their tokenized IDs; runtime proof additionally needs an agent online with a compatible presence status (service-omni-presence-status-deploy).
• The three-way safe_to_write production guard applies.

Run

deploy-and-report.sh deploys, verifies, and (per variant) proves routing:

1. Resolve tokens (record-triggered only) — the committed asset carries __QUEUE_ID__, __ROUTING_CONFIG_ID__, __SERVICE_CHANNEL_ID__, and channel name/label tokens. The skill resolves each by DeveloperName into a materialized copy that is never committed (the asset stays tokenized for portability). A ServiceChannel that does not resolve fails closed rather than embedding an empty id.
2. Deploy — sf project deploy start --metadata "Flow:<FlowDN>"; the files[].state maps to reused/updated/created.
3. Verify Active — retrieve the Flow and confirm its resource IDs, routingType, and SkillsBased skillOption still match; otherwise redeploy. Confirm an active version exists.
4. Prove routing — autolaunched: POST to /actions/custom/flow/<FlowDN> with {"dryRun":true} and assert isSuccess and dryRunOk. Record-triggered: insert a target record and observe routing. SkillsBased success additionally requires one or more SkillRequirement rows on the PSR.