THREE WORKED SUPPORT AUTOMATION RECORDS
FullSession | 19 October 2026

Status: illustrative workflow designs, not observed product tests or customer results. The example SaaS application's policy is invented: workspace admins may create alerts; members may view them. Replace it with your actual application policy, schema, connections and approval requirements. These records do not claim a specific FullSession role/alert configuration or an already-built integration.

RECORD 1: ANSWER THE PERMISSION QUESTION
Request: Can I create an alert, or do I need our admin?
Customer job: Understand who may create an alert and the appropriate next step.
Knowledge/data: Approved current role policy and alert guide. Account-specific statement requires authenticated user and role in the current workspace.
Permitted work: Answer the policy question; show the next step. Do not change account roles, reveal another workspace's information or claim to know an unauthenticated person's role.
Normal path: Find the relevant policy; state required role and condition; if identity is available and authorized, explain the person's next step; otherwise keep the answer general.
Success signal: Reviewed answer agrees with policy and states the relevant condition. If the user requests setup and is eligible, pass into record 2.
Human path: Workspace admin for missing permission. Support/source owner for conflicting policy and app behavior.
Evidence to retain: Approved source/version, question, answer, relevant condition and any exception destination. Avoid retaining unnecessary identity data.
Acceptance tests: Correct admin case; member case; unauthenticated case; source conflict; question about another workspace.
Owner: Support workflow owner; policy owner for source correctness.

RECORD 2: COMPLETE THE PERMITTED SETUP
Request: Create an error alert for this workspace and notify me.
Customer job: Save the intended alert under the allowed scope.
Knowledge/data: Current alert guide, authenticated workspace and role, supported alert fields, requested configuration and notification destination.
Permitted work: Prepare the supported configuration; obtain required confirmation; save only in the authorized workspace. Do not change unrelated alerts, roles, plans or account access.
Normal path: Clarify missing fields; check identity/permission; prepare requested fields; request confirmation where policy requires; perform supported operation; inspect resulting saved state.
Success signal: Confirmed saved record and settings match request. Present what was created and where it is available. Saving an alert does not prove a later notification was delivered.
Uncertain-result path: If the connection times out, inspect whether the intended record exists before retrying. Keep outcome unknown if sufficient evidence is unavailable. Do not tell the user an uncertain save succeeded.
Human path: Workspace admin if not permitted. Support if save fails or state cannot be established; continue into record 3.
Evidence to retain: Authorized scope, requested configuration, required approval, attempted operation and resulting state. Use permitted data only.
Acceptance tests: Normal successful save; missing detail; denied permission; declined confirmation; connection failure before save; timeout after possible save; duplicate request; mismatching saved fields.
Owner: Support workflow owner and application connection owner.

RECORD 3: HAND OVER THE FAILED SAVE
Request: It still will not save. I need help.
Customer job: Reach the responsible person with the work already attempted preserved.
Knowledge/data: Requested configuration, authorized workspace, attempted operation, available error/result information, relevant conversation and receiving-team availability.
Permitted work: Stop failed action loop; explain known status; route the conversation/case to the defined human destination. Do not fabricate cause, completion or response deadline.
Normal path: Record whether save definitely failed or may have succeeded; preserve relevant history; identify recipient; tell customer who owns the next step and actual availability.
Success signal: Correct human destination, usable context and truthful availability message. This is a handoff result; the underlying customer problem remains unresolved until verified.
Unavailable-team path: Use approved service-hours/away message and retain follow-up destination. Do not promise an immediate reply. Check next review/follow-up ownership according to the team's real process.
Human path: Person investigates configuration, permission or product failure; confirms the final result before resolving the underlying problem.
Evidence to retain: Request, attempted change, known/unknown result, required follow-up and assigned owner. Use optional session context only when actually available and permitted.
Acceptance tests: Known failed save; unknown save state; customer asks for person immediately; unavailable teammate; permission failure routed to correct owner; sensitive data excluded from unnecessary notes.
Owner: Receiving queue owner, with the support workflow owner responsible for the handoff design.

COMPARE RESULTS ACROSS THE THREE RECORDS
An answer is not a saved alert. A saved alert is not proof of notification delivery. An owned handoff is not proof the original problem is fixed.
Record actual results separately. No target deflection percentage, staffing saving or guaranteed improvement is assumed.

Published demonstration reference, separate from these designs:
https://www.fullsession.io/compare/fullsession-vs-intercom
The existing clip uses FullSession's own app and includes Daleel branding; it illustrates on-screen co-driving, not a configured Max deployment in your application.

Desk walkthrough:
https://www.fullsession.io/book-a-demo?solution=support-desk