Workflow Execution · Trust Addendum

This document supplements the flowscope Security and Trust Overview with the controls that apply to any flowscope workflow product: an agent that takes input from the customer's environment, reasons over it, and either takes a downstream action automatically or hands off a proposed action to a human reviewer for approval.

Reviewer scoping

Where a workflow involves a human reviewer, that reviewer is scoped to the workflows they are assigned to and only sees runs that belong to those workflows. Reviewer and admin roles are distinct. A reviewer cannot expand their own scope, and the role grant itself is logged as an admin action.

Human authorization

Workflows that take an action with material consequences for the customer are queued for a named human reviewer before that action is dispatched. For each pending run, the reviewer sees the input that triggered the run, the structured representation flowscope built from it, the proposed action, and the reasoning trace that led to it. They can approve as-is, edit field values then approve, or reject with a reason. All three decisions write to the audit log.

The threshold above which an action requires human authorization is set per workflow at deployment time and is not changed without a written change request from the customer.

Integration

flowscope acts through the customer's own systems rather than around them. Where a target system exposes an API, the workflow integrates through it directly, translating the authorized action into that system's own create or update call; flowscope operates no standing browser-automation tooling and does not drive a web interface by default. Where a required system exposes no suitable API, a narrowly scoped computer-use approach may operate that system's interface, only where strictly necessary and only by separate written agreement scoped per engagement, running exclusively on dedicated virtual desktops and never on employee machines. Either way the action dispatched is the one a named reviewer approved, the credentials used are the customer-issued credentials described below, and the identifier of the resulting downstream record is written to the audit log.

Audit log

Every workflow run produces an append-only record, retained per the platform retention policy, that captures the inputs received, the proposed action, the reviewer's identity and decision (where authorization applied), the timestamp of each step, and the identifier of the resulting downstream record on successful dispatch. The audit log cannot be rewritten by flowscope or by the customer; corrections happen by creating a new corrective workflow run.

Customer-issued credentials

Where a workflow writes back to a customer-side system, the credentials issued to flowscope for that purpose are scoped to the workflows that use them and are never reused across customers. They are held in the managed secrets store described in the platform overview, and are rotated on customer request, on suspected compromise, and on operator offboarding.

Failure handling

If any step in a workflow run fails (input parsing, reasoning, downstream dispatch), the run is marked failed and surfaced to the assigned reviewer with the underlying error. The original input and any derived structures remain attached to the run record, so a failed run can be retried, edited, or escalated without re-ingesting the source. No input is dropped silently; every ingested input terminates either in a successful dispatch with a recorded downstream identifier, an explicit reviewer rejection, or a failed-run state that requires human triage.