Skip to content

Browser-based form completion with approval gates

Prepare and execute browser-mediated form submissions through explicit approval checkpoints, with strong exception handling for sensitive or irreversible outcomes.

Metadata

  • Pattern id: browser-based-form-completion-with-approval-gates
  • Pattern family: Execute / Automate
  • Problem structure: Approval-gated execution (approval-gated-execution)
  • Domains: Finance (finance), Compliance (compliance), HR (hr)

Workflow goal

Convert an approved request into a correctly completed browser-based transaction or submission while enforcing formal sign-off, preserving evidence, and stopping safely on policy conflicts or execution exceptions.

Inputs

Approved task request

  • Description: A request package describing the intended submission, target system, required fields, and authority to proceed once approvals are satisfied.
  • Kind: request
  • Required: Yes
  • Examples:
  • Submit a payroll profile change after manager and payroll approval
  • File a regulated portal update after compliance review

Form data and supporting documents

  • Description: Structured field values, attachments, and reference materials needed to complete the browser workflow accurately.
  • Kind: form-packet
  • Required: Yes
  • Examples:
  • Approved vendor banking details and tax documentation
  • Employee status change data with supporting forms

Approval state and policy controls

  • Description: Formal approvals, segregation-of-duties checks, submission thresholds, and policy rules that gate execution.
  • Kind: approval-record
  • Required: Yes
  • Examples:
  • Signed approval record authorizing submission to the target portal
  • Policy check showing dual approval for bank-account changes

Runtime browser context

  • Description: Live session details, authentication context, page state, and detected UI conditions during execution.
  • Kind: execution-state
  • Required: No
  • Examples:
  • Browser page showing a changed field layout
  • Portal warning requiring additional confirmation

Outputs

Submitted transaction record

  • Description: Evidence that the form was completed and either submitted, saved for review, or halted before commit.
  • Kind: execution-result
  • Required: Yes
  • Examples:
  • Submission confirmation with portal reference number
  • Saved draft awaiting a final human approval token

Execution evidence bundle

  • Description: Trace of filled fields, approvals used, checkpoints passed, attachments uploaded, and browser observations.
  • Kind: audit-packet
  • Required: Yes
  • Examples:
  • Field-by-field trace with screenshots at approval gates
  • Record of which approval token unlocked final submission

Exception and fallback log

  • Description: Structured record of validation failures, UI changes, policy conflicts, and human takeover points encountered during execution.
  • Kind: exception-log
  • Required: Yes
  • Examples:
  • Portal timeout that triggered safe retry and review
  • Policy mismatch that blocked final submission

Environment

Operates in operational systems that expose critical actions through browser interfaces, where execution is feasible to automate but control gates, fragile UIs, and consequential submissions demand conservative behavior.

Systems

  • Browser-accessed enterprise portals
  • Approval and ticketing systems
  • Identity and access management systems
  • Evidence storage or audit systems

Actors

  • Request owner
  • Approving reviewer
  • Operations or compliance executor
  • System administrator

Constraints

  • Do not submit final actions until all required approval conditions are positively verified.
  • Preserve enough evidence for reviewers to confirm what was entered and why.
  • Stop safely on UI drift, missing fields, policy conflicts, or ambiguous confirmation states.
  • Respect least-privilege access and segregation-of-duties boundaries for portal interactions.

Assumptions

  • Target systems expose browser workflows that can be automated or assisted reliably enough to justify the pattern.
  • Approval state can be checked against a trusted source before submission proceeds.
  • Human reviewers are available to take over when approvals, UI state, or confirmation signals are unclear.

Capability requirements

  • Tool use (tool-use): The workflow must operate real browser sessions, navigate pages, upload files, and interact with external portals.
  • Action execution (action-execution): Success depends on carrying an approved request through to an actual saved or submitted system change.
  • Policy and constraint checking (policy-and-constraint-checking): Approval tokens, segregation-of-duties rules, and submission thresholds determine whether execution may continue.
  • Verification (verification): The workflow must confirm field values, approval state, and final submission outcomes against trusted signals.
  • Exception handling (exception-handling): Browser automation must recover safely from layout drift, missing data, portal warnings, or ambiguous confirmation states.
  • Memory and state tracking (memory-and-state-tracking): Multi-step browser workflows require durable state for completed checkpoints, attachments, retries, and takeover points.

Execution architecture

  • Approval-gated execution (approval-gated-execution): The workflow is defined by an execution package that remains technically ready but blocked until explicit approvals and policy checks unlock submission.
  • Tool-using single agent (tool-using-single-agent): A single browser-automation agent can often carry the request through page navigation, field entry, and evidence capture within one controlled loop.
  • Human in the loop (human-in-the-loop): Human checkpoints remain part of the normal operating model because final submission authority and exception resolution cannot be delegated away.

Autonomy profile

  • Level: Approval gated (approval-gated)
  • Reversibility: Some drafts or saved forms can be reversed, but final portal submissions may be slow, costly, or impossible to unwind once accepted by the external system.
  • Escalation: Escalate whenever approval state is incomplete, field-level confidence is low, the browser workflow diverges from expected UI state, or the submission would create a high-impact irreversible outcome.

Human checkpoints

  • Review the prepared submission packet and confirm approvals before the browser workflow enters its final commit path.
  • Approve any override, retry beyond normal bounds, or execution path affected by UI drift or policy ambiguity.
  • Confirm the final evidence bundle when the target action changes regulated records, payroll, funds, or other highly sensitive state.

Risk and governance

  • Risk level: Critical (critical)
  • Failure impact: Incorrect or unauthorized submission can create severe financial loss, regulatory breach, payroll harm, privacy exposure, or other systemic consequences that may be difficult to reverse.
  • Auditability: Preserve submission intent, approval evidence, field-level inputs, screenshots or equivalent browser traces, retry history, and final confirmation artifacts so the full execution path can be reconstructed.

Approval requirements

  • Final submission requires explicit verification of all required human approvals and policy checks immediately before commit.
  • Overrides for UI drift, changed portal behavior, or sensitive data mismatches require a human reviewer to approve or take over the task.

Privacy

  • Minimize retention of sensitive personal, payroll, banking, or regulatory data outside approved evidence stores.
  • Mask or restrict screenshots and logs that contain confidential information.

Security

  • Use tightly scoped credentials, session isolation, and strong logging for all browser automation actions.
  • Enforce segregation of duties so the same authority does not both approve and silently execute a sensitive submission without oversight.

Notes: Critical-risk posture is warranted because this pattern crosses from preparation into real-world system change in environments with limited tolerance for error.

Why agentic

  • Browser workflows often require adaptive action selection because page layouts, validation messages, and branching paths vary at runtime.
  • Safe execution depends on stateful tracking of approvals, entered fields, and exception paths across multiple steps rather than one-shot scripting.
  • The workflow must decide when to pause, retry, or escalate instead of blindly completing a brittle automation path.

Failure modes

The workflow submits without a valid approval gate

  • Impact: A consequential system change occurs without the required human authorization or policy basis.
  • Severity: critical
  • Detectability: medium
  • Mitigations:
  • Re-verify approval state from a trusted source immediately before final commit.
  • Block submission when approval evidence is missing, stale, or inconsistent.

Browser UI drift causes data to be entered into the wrong fields

  • Impact: The target system records incorrect information and downstream correction becomes costly or slow.
  • Severity: critical
  • Detectability: low
  • Mitigations:
  • Use structural page validation before and after sensitive entry steps.
  • Escalate to human review when expected labels, confirmation text, or field mappings differ.

Confirmation state is ambiguous after submission

  • Impact: Operators cannot tell whether the action committed, leading to duplicate submissions or missed obligations.
  • Severity: high
  • Detectability: medium
  • Mitigations:
  • Require positive confirmation signals or reference numbers before marking completion.
  • Route ambiguous outcomes into a human-controlled reconciliation path.

Sensitive evidence leaks through logs or screenshots

  • Impact: Privacy, compliance, or security obligations are breached during otherwise controlled automation.
  • Severity: high
  • Detectability: medium
  • Mitigations:
  • Mask sensitive fields in evidence capture where possible.
  • Restrict access to execution traces and enforce retention limits.

Evaluation

Success metrics

  • Percentage of approved browser tasks completed without unauthorized submission or manual rework.
  • Rate of exception cases stopped safely before an incorrect final commit.
  • Completeness of execution evidence for reviewed submissions.

Quality criteria

  • Every submitted action is traceable to a verified approval state and an inspectable execution record.
  • The workflow stops or escalates on ambiguous UI or policy conditions instead of guessing.
  • Browser automation remains aligned with least-privilege and segregation-of-duties expectations.

Robustness checks

  • Test with realistic UI changes and confirm the workflow escalates before filling or submitting the wrong form.
  • Test expired or conflicting approval records and ensure final submission remains blocked.
  • Test network and portal timeouts to verify retries stay bounded and do not create duplicate submissions.

Benchmark notes: Evaluate controlled completion and safe failure handling together; raw submission throughput is not meaningful if the workflow cannot prove approval integrity.

Implementation notes

Orchestration notes

  • Separate packet preparation, approval verification, browser execution, and confirmation capture so control gates are inspectable.
  • Keep checkpoint state durable enough for human takeover after any interruption or exception.

Integration notes

  • Common implementations integrate browser automation, approval systems, ticketing, and evidence storage.
  • Keep the pattern neutral about specific RPA tools, browsers, or enterprise portals.

Deployment notes

  • Roll out first on high-volume but tightly governed workflows where browser automation is already partially standardized.
  • Revalidate selectors, confirmation signals, and masking controls continuously as portal UIs evolve.

References

Example domains

  • Finance (finance): Submit a vendor banking update through a browser-only finance portal after dual approval and evidence capture.
  • Compliance (compliance): File a regulated disclosure update through a portal that requires documented review before final submission.
  • HR (hr): Complete a sensitive employee status or payroll change in a browser workflow only after required manager and payroll approvals.

Grounded instances

Canonical source

  • data/patterns/execute-automate/browser-based-form-completion-with-approval-gates.yaml