Opus core concepts
What Opus is
Opus is a low-code platform for automating workflows and building business rules. It consists of two components: the OPUS Management System (OMS) for authoring and managing, and the OPUS Execution Server (OES) for running automations via API.
Why Opus works this way
Two building blocks: workflows and decisions
Opus separates process automation from business logic into two distinct building blocks.
| Building block | What it does | When to use |
|---|---|---|
| Workflow | Automates sequences of steps across systems (API calls, file transfers, notifications) | Processes that cross system boundaries and need execution tracking |
| Decision | Evaluates input data against rules and returns an outcome | Eligibility checks, validations, computations — rules that change independently of code |
Decisions can be embedded within workflows. This separation means business rules can be updated without modifying the workflow that calls them, and the same decision can be reused across multiple workflows.
Nodes: the building blocks of graphs
Workflows and decisions are built from nodes — individual components that each perform one action. Nodes connect into a directed graph that defines how data flows through the automation.
Opus provides 35+ node types in three categories:
- Basic nodes — general-purpose: API calls, functions, file conversion, conditional branching, delays, storage
- WoG nodes — pre-connected to government platforms: APEX, CFT, GovWallet, AISay, BookingSG, Postman, Ownself Gather
- Trigger nodes — entry points that start workflows: API input, ApplySG, CFT, FormSG, Email, GovRewards
WoG nodes exist because government agencies would otherwise need to build custom API integrations for each platform. Pre-connected nodes handle authentication, payload formatting, and error handling automatically.
The life cycle model
The following diagram shows how a workflow or decision moves from authoring to production, including the regression testing loop.
Automations start in the authoring phase, where developers build and simulate with sample data. Once simulation passes, the automation is published — creating a committed version. Regression testing validates all test suites across the project. If tests pass, a release creates a versioned production snapshot. If tests fail, developers return to authoring to fix issues.
| Stage | What happens | Environment |
|---|---|---|
| Author | Build and configure in the visual editor | OMS |
| Simulate | Test with sample or mock data | OMS (local) |
| Publish | Commit a new version of the workflow or decision | OMS → Staging |
| Run/Test | Execute in staging with real integrations | OES (staging) |
| Regression test | Validate all test suites across the project | OES (staging) |
| Release | Create a versioned snapshot for production | OMS → Production |
| Execute | Run via API endpoint in production | OES (production) |
Staging and production separation
Opus provides separate environments for testing and live operations.
- Staging is used for testing with real integrations after publishing. Execution here does not affect production data.
- Production is used for live operations after a release is created.
Each environment has its own API endpoints, access tokens, and execution history. This prevents test data from contaminating production and allows teams to validate changes safely.
Versioning and release management
Opus uses Git-like versioning with branching. Each publish creates a committed version. Releases snapshot all published artifacts in a project for production deployment.
- Draft — uncommitted changes, visible only to the author
- Published — committed version, available for staging testing and inclusion in releases
- Released — production-ready version, executable via the production API endpoint
Roles and access control
Access is controlled through three roles:
| Role | Scope |
|---|---|
| Administrator | Full access: projects, users, tokens, billing |
| Editor | CRUD on workflows, decisions, and test suites within assigned projects |
| Viewer | Read-only access to assigned projects |
All users authenticate via TechPass. Administrators invite users and assign them to projects with a role. Access tokens (per-project, per-environment) authenticate API calls from external systems.
Related content
- Get started with Opus — sign up, create a project, build your first workflow.
- How to build workflows and How to build decisions — step-by-step configuration guides.
- How to publish and release — the full life cycle from publish to production.
- Node reference — configuration details for all 35+ node types.
- Limits and constraints — platform limits for workflows, decisions, and payloads.
