Skip to content
Kacper Walat
Services
Process blueprint / 01

Request-to-ResolutionProcess Blueprint

A practical operating model for reliable Salesforce automation across Flow, Apex and Agentforce.

Download PDF Explore the Flow build
DemoCoFictional B2B SaaS scenarioIllustrative architecture / synthetic data

Sample build using synthetic data in a Developer Edition org. Created to demonstrate architecture and delivery approach; not presented as client work.

Executive snapshot

One governed path. Clear ownership.

The blueprint aligns process design, automation boundaries and operational controls.

Design objective

Predictable by design

Create one predictable path from request intake to resolution while keeping business policy configurable, complex routing testable and AI actions controlled.

01Casesystem of record
03LayersFlow / Apex / Agent
04Typesrequest scenarios
Explicit non-goals
  • No autonomous high-risk approval
  • No production or client data
  • No performance claims
state

Single source of truth

Case owns request state, ownership and lifecycle.

orchestrate

Flow owns the process

Visible business steps stay modular and fault-aware.

decide

Apex owns complex routing

A bulk-safe service returns results without updating Case.

assist

Agent actions stay constrained

Guidance first; record writes require confirmation.

evidence

Decisions stay observable

Correlation IDs and audit events support review.

Current state

Where reliability breaks down

An illustrative scenario used to define the demonstrator — not a statement about a real company.

IntakeRequest arrives
TriageManual review
OwnerOwner search
PolicyGuidance lookup
HandoffContext rewrite
CloseResolution

Friction map

StageFrictionConsequenceSignal to capture
IntakeContext varies by channelRework before routingMissing field reason
TriageRules live in team memoryInconsistent assignmentRouting decision
OwnershipCapacity is not explicitSilent fallbackQueue and fallback code
PolicyGuidance is scatteredDifferent answersKnowledge source used
EscalationFollow-up is manualLate or duplicate actionDue time and reason
HandoffContext is rewrittenDetail lossHandoff summary
Target architecture

A controlled Request-to-Resolution spine

Each layer has a clear job; exceptions use the same observable recovery path.

ExperienceInternal users + Ops Concierge
OrchestrationNormalize + validate + SLA + fault path
Decision servicesRouting Engine + metadata policy
System of recordAccount + Contact + Case + Knowledge + Log
ControlsConfirmation + access + idempotency + evidence
Primary path
  1. 01Intake
  2. 02Normalize
  3. 03Validate
  4. 04Select SLA
  5. 05Route
  6. 06Act
  7. 07Verify
  8. 08Resolve
Controlled exception
  • Write audit event
  • Preserve Case state
  • Route to Triage
  • Notify owner
Decision matrix

Choose the tool by responsibility

The simplest tool is the one that keeps the decision testable, observable and owned.

DecisionDefault toolWhyBoundary
Normalize Case fieldsFlowDeclarative and visibleBefore-save only
Orchestrate lifecycleFlowReadable business sequenceKeep decisions modular
Resolve routingApexDeterministic and bulk-testableReturns result; no Case DML
Store policyMetadataDeployable configurationValidate missing config
Provide guidanceAgentforceApproved knowledge in contextNo record write
Create or escalateAgent + FlowReuses governed automationConfirmation required
High-risk judgmentHumanAccountability and contextAgent must escalate
Ambiguous exceptionDo not automateReliability value is unclearTrack frequency first
Controls

Make failure safe and reviewable

Guardrails apply before, during and after an automated decision.

InputRequired context
DecisionStable rules
ActionConfirmation
AccessLeast privilege
RecoveryTriage fallback
EvidenceAudit event
Failure modeSystem responseHuman visibility
Missing inputNEEDS_INPUT; no owner changeMissing field list
No active ruleFALLBACK to TriageFallback reason
Capacity reachedNext rule, then fallbackDecision code
Missing fallbackControlled config errorFault + owner alert
Resolved before SLAExit without escalationOptional audit
High-risk intentStop autonomous pathCompliance handoff
Injection / data breachRefuse actionSecurity audit event
Delivery backlog

Build the governed spine before the agent

Order reflects dependency and risk reduction, not measured return on investment.

Now

Governed spine

Dependency stage 01
  1. Define Case state and intake fields
  2. Normalize, validate and correlate
  3. Build Routing Engine contract
  4. Add fault log and Triage fallback
  5. Test exact match and batch paths
Foundation
Next

Operational resilience

Dependency stage 02
  1. Add scheduled SLA re-check
  2. Define queue capacity policy
  3. Publish synthetic Knowledge
  4. Expose outcomes and fallbacks
Resilience
Later

Constrained agent pilot

Dependency stage 03
  1. Release guidance-only topics
  2. Add confirmed Case actions
  3. Run adversarial prompt tests
  4. Review audits before expansion
Controlled scale
Validation + handoff

Evidence before expansion

Readiness is demonstrated through controls and tests — metrics are defined only after deployment.

Readiness gates
  • Process states and ownership documented
  • Routing rules have an accountable owner
  • Happy, fallback and fault paths tested
  • Seed is synthetic and idempotent
  • Agent writes require confirmation
  • Logs exclude secrets and production PII
  • Rollback and Triage paths exercised
Metrics to establish
  1. M01Intake completeness
  2. M02Routing outcome distribution
  3. M03Fallback / NEEDS_INPUT rate
  4. M04Reassignment count
  5. M05SLA escalation review
  6. M06Agent confirmation / refusal / handoff

Definitions only. Baselines and targets require a real, isolated environment.

Recommended validation sequence
  1. 01Developer org
  2. 02Automated tests
  3. 03Business walkthrough
  4. 04Constrained pilot
  5. 05Control review
  6. 06Staged expansion

Salesforce, Agentforce and Apex are trademarks of Salesforce, Inc. This sample is independent and is not endorsed by or affiliated with Salesforce, Inc.