How we keep your workflow running

Infrastructure and hosting

We run client workflows on AWS, using the Singapore or Malaysia region depending on the workflow's requirements. We make hosting choices per workflow rather than applying one setup to everyone, because a high-volume claims process and a small intake workflow do not need the same infrastructure.

Where a workflow runs inside your own environment, we operate it there. We work directly with Microsoft 365 and Google Workspace, so the workflow sits where your team already works rather than forcing a move to somewhere new.

Identity and access

We give people access to the workflow they operate and nothing wider. Access is role-based, granted for the work that requires it, and removed when it is no longer needed.

Where your environment supports single sign-on, we use it, so access follows your existing identity controls rather than creating a separate set of logins to manage. We review who holds access on a regular basis and remove anything that is no longer in use.

Backups and recovery

We back up the files and workflow records that matter, and we test that the backups actually restore. A backup that has never been restored is an assumption, not a safeguard, so we verify it.

We agree the specifics with you per workflow: how often we back up, how long we retain, how much data you can afford to lose if something fails (the recovery point), and how quickly we need to be running again (the recovery time). These depend on what the workflow does and how critical it is, so we set them against your requirements rather than quoting a single number that fits nobody.

Monitoring

We watch three things across every workflow we operate. When something crosses a threshold, we get alerted, and the alert reaches the person responsible for that workflow.

You do not have to notice a problem and report it to us. We are watching the workflow so that we see it first.

Incident handling

When something goes wrong, we work to a defined practice rather than improvising.

We sort incidents by severity, from a minor issue that does not interrupt the work to a full outage that stops it. The severity sets how fast we respond and how we communicate. During an incident we keep you informed rather than going quiet, and after we have resolved it we review what happened and what we change so it does not recur.

Where an incident involves personal data, it also engages our obligations under the Personal Data Protection Act. We handle that in line with how we describe breach obligations on our data-handling page, and we treat any access we hold to your data as in scope for that duty.

How we handle providers

We build workflows on a defined set of providers: Anthropic, Cloudflare, Google, Microsoft, Neon, OpenAI, Supabase, and Vercel. We use them for hosting, data storage, delivery, and the AI steps inside a workflow.

We evaluate each provider before we rely on it, and which providers a given workflow touches is a decision we make per workflow, not a fixed list applied to everyone. For what each provider receives and how we limit what is sent to the AI steps specifically, see our data-handling page.

How workflows fail safely

A workflow we operate is built to degrade safely rather than break silently.

When a step cannot complete, the work holds in a queue instead of disappearing, and we recover it. Where a change carries risk, we roll it out gradually and we keep a path back to the previous state.

This is the difference between an operated workflow and automation that runs until it quietly stops. We monitor the workflow, we hold failed work where we can see it, and we restore it rather than leaving your team to discover the gap later.