Workflows

EZGH Workflows runs durable workflows written as code in your own application. A workflow is an ordinary TypeScript, Go or Python function whose side effects are wrapped in named steps. EZGH records each step’s result, so a run survives crashes, deploys and outages. It retries what failed, sleeps for minutes or months, waits for callbacks, starts child workflows and runs steps in parallel. Schedules start runs on a cron timetable.

Your code runs where you deploy it. EZGH either pushes signed requests to your HTTPS endpoint, or your pull workers poll EZGH for work and need no public endpoint.

SDKs

The SDKs are open source (Apache-2.0) on GitHub. They aren’t published to npm or PyPI yet: install them from GitHub by tag.

Each SDK has no runtime dependencies. Its README is the full reference for its API.

Hosts

The SDKs know both hosts; you give them an API key, an organization ID and a project ID. The ezgh workflows commands manage apps, runs, schedules and callbacks from the command line.

Permissions

• An app is the resource ezgh:<region>:<org>:<project>:wfa_<slug>. Run actions are checked on the workflow: the app’s resource name with the workflow’s name as its path, …:wfa_<slug>/<workflow>. So a policy on …:wfa_*/billing-* allows only the workflows whose names start with billing-. workflows.runs.list is checked on the project, so it lists every run in the project, without inputs or outputs.
• A schedule is the resource …:wfs_<slug>. Creating a schedule, changing anything but its name, resuming it and triggering it also need workflows.runs.start on its workflow. Reading a schedule’s input needs workflows.runs.getPayload on its workflow.
• workflows.runs.getPayload is a write-level action, so ReadOnlyAccess never reads inputs or outputs.

Each also allows organizations.get, projects.list and projects.get. ReadOnlyAccess allows what WorkflowsReadOnlyAccess does. AdministratorAccess and the root user can do all of these. API keys act with their owner’s access: give a workload a key for a bot with only the access it needs. See IAM.

EZGH SSO: Workflows actions can be granted to a directory’s users by policy. An EZGH SSO resource token with the workflows:runs scope is limited to the workflows.runs.* actions and workflows.callbacks.complete, on top of the user’s own policies.

Data

• Inputs, outputs and callback bodies are your data: they’re readable only with workflows.runs.getPayload, and never appear in Trails. A run’s events contain IDs, counts and error codes, never payloads.
• A run’s data is deleted 30 days after the run ends: its steps, history, inputs and outputs. Its run key can then be used again.
• Deleting a project or organization deletes its Workflows apps, schedules and run data within an hour; see Limits and usage.

Trails

Workflows’ events have the event source workflows.ezghcloud.com.

• Recorded: changes to apps and schedules (CreateApp, UpdateApp, DeleteApp, SyncApp, RotateAppSecret, CreateSchedule, UpdateSchedule, DeleteSchedule, PauseSchedule, ResumeSchedule, TriggerSchedule), CancelRun, RetryRun, and AnnounceWorkflows when a pull worker’s announcement changes an app’s workflows. Reads follow the rules for reads; listing runs (ListRuns) and reading limits (GetLimits) aren’t recorded.
• Recorded only when refused: StartRun, CompleteCallback and PollTasks. Successful starts, completions and polls produce no event.
• Never recorded: runs started by schedules and child workflows (no request started them), callbacks completed by their URL (no credential), and the SDKs’ calls while a run executes.