No-Code SaaS Automation Platform  ·  View 03 of 21  ·  People and journeys

Actors and Their Journeys

Five parties, their goals in their own words, and the journeys each of them gets. Two have their own map.

Editable source SVG draw.io All views
The people who build and depend on automations Automation author Goal — I work in ops, sales or finance. Make the busywork between my tools disappear without asking engineering, and let me trust it is still running next quarter. Core journeys Build and publish one 12 M live Repair one that stopped Replay a run that failed Workspace admin Goal — I own IT and security here. Know which of our SaaS accounts this platform can reach, on whose authority, and cut any of it off in a minute. Core journeys Review connected accounts Revoke a connection Approve a shared-connection automation The people and machines that keep it running Platform operator Goal — I am the SRE on call. Tell me within a minute whether the backlog is our fault or a provider's, and shed the right load either way. Core journeys Triage a rising backlog Trip a provider breaker Connector developer partner or in-house Goal — Ship a connector for my product and have its replay safety stated honestly rather than guessed. Core journeys Publish a connector version Deprecate an old version Provider API quota owner Goal — Not be hammered. Have one caller I can identify, allowlist and rate-limit predictably. Core journeys Receive governed traffic Signal backoff and be obeyed Scheduler clock-driven Goal — Fire the scheduled and polled triggers on time without aligning a million connections on the minute. Core journeys Advance a connection cursor Who It Is For, and What They Get To Do Person or role Journey / task Application we own External / third party Security / platform Goals are in each actor's own voice; the two journeys with ids get their own map. v 1.0 · owner Integration Platform Architecture · date 2026-10

Why these five

  • The author is not an engineer, and that single fact drives Section 9 of the requirement: a failure they cannot read is an unfinished feature.
  • The provider API is listed as an actor with a goal because it is the only party that can throttle us, and designing as if it were passive is how platforms get their application credentials suspended.
  • The connector developer is an actor because the catalogue is the growth ceiling, and their incentive is to ship rather than to classify replay safety honestly.

Assumptions

  • 2.5 M active workspaces, 12 M enabled automations — so the median author owns a handful, and the distribution has a long dormant tail.
  • The workspace admin and the author are usually different people, and the admin finds out about a connection after it exists.

Risks

  • The operator cannot distinguish our backlog from a provider's slowness without the per-provider health signal in view 17.
  • Nobody in this cast is accountable for a dormant automation that will fire wrongly in six months.
◀  High-Level Architecture All views Journey — Building the First Automation  ▶
Solution Architecture v1.0 · Amazon Web Services · Integration Platform Architecture · 2026-10 · 21 views03-actors-and-journeys