A system is EmpowerNow's name for a connected external API or service — Salesforce, Entra ID, ServiceNow, your own internal microservice, anything that speaks HTTP. Once registered, every command you define on that system becomes a building block your workflows and AI agents can call. By the end of this guide you'll have one fully wired system with a working command.
1 Open the Systems list
Go to /systems
From the EmpowerNow side navigation choose System Editor, or open the URL directly. You land on the Systems hub with stats cards on top, a toolbar of view toggles, search, and type filter, and the list of every system already registered for your tenant.
To see the Create button you need system-editor:system with the create action. Without it, the button is hidden by the Protected component.
2 Click Create New System
Hit the teal button on the top-right
The ✨ Create New System button is in the top-right corner. Clicking it navigates you to /system-editor/new — a multi-tab editor that's already in create mode. The first tab, System Details, is open and waiting for metadata.
Nothing has been written to the server. The system isn't real until you fill in the required fields and hit Save in the top-right of the editor. Closing the tab here loses everything.
3 Set name, type, description
Fill in the System Details tab
| Field | What to enter | Notes |
|---|---|---|
| System Name * | Lowercase slug, no spaces | e.g. helpdesk-api. Becomes the system's permanent id — workflows reference it by this name. |
| Description | One-line summary | Visible on cards and to anyone browsing the gallery. |
| Version | Defaults to 1.0.0 | Bump it when you change the contract. |
| Tags | Comma separated, optional | e.g. itsm, ticketing, internal. Used to filter the list. |
| System Type * | Choose from dropdown | Common picks: oauth-rest (OAuth 2.0 + REST), basic-rest (basic auth + REST), graphql, or a custom type your admins added. |
Once saved, you can't rename a system without breaking every workflow that calls it. Choose carefully on day one. The Description and Tags fields are safe to change later.
4 Optional shortcut — import an OpenAPI spec
If your API ships an OpenAPI 3.x file, use it
Importing OpenAPI auto-generates everything — object types, every command (GET / POST / PUT / DELETE), parameters, request/response schemas. You go from blank to fully-loaded in 30 seconds.
- Click the Import OpenAPI button at the top of the editor.
- Provide a URL (
https://api.example.com/openapi.json), upload a file, or paste raw YAML/JSON. - The wizard previews everything it found. Untick anything you don't want.
- Click Apply. The Designer tab fills with object types and commands.
It's perfectly fine to define commands manually. Most internal systems work that way. Continue to step 5; we'll add a command by hand later in step 7.
5 Configure Connection & auth
Switch to the Connection tab
Click the Connection tab. Two fields are essential — everything else has sensible defaults:
| Field | Example value | Notes |
|---|---|---|
| Base URL * | https://api.example.com/v1 | The root every command's path is relative to. |
| Auth Type * | OAuth 2.0 · API Key · Basic · Bearer · None | Most modern APIs are OAuth 2.0. Pick the right one — the form below adapts. |
| TLS verification | On (default) | Only turn off for dev environments with self-signed certs. |
| Timeout (ms) | 30000 | Increase for slow APIs. |
| Rate limit / retries | Optional | Set conservative defaults so a misbehaving workflow can't hammer the upstream. |
Use environment variable references like ${API_TOKEN} or Vault references like vault://secret/path#field. The Connection form resolves them at runtime; the literal value never leaves the secret store.
Pick a preset, set scopes
If your auth type is OAuth 2.0, a separate OAuth tab appears. Use a preset (Microsoft Entra, Salesforce, Okta, generic) to auto-fill authorize/token URLs, then fill in:
- Client ID / Client Secret (use env-var references).
- Scopes — what permissions to ask for at consent.
- PKCE on for public/native clients.
- Token endpoint authentication method — usually
client_secret_postorclient_secret_basic.
6 Test the connection
Click Test Connection — don't skip this
Still on the Connection tab, click the Test Connection button at the bottom. EmpowerNow performs a lightweight call against the base URL using the configured auth and reports back.
200 OK · 142 ms · TLS verified · Bearer token issued (sub: app-svc-acct)
If it fails, the panel shows the exact HTTP status, response body, and any TLS/redirect/auth issues. Common gotchas:
- 401 Unauthorized — Client ID/secret wrong, or scopes don't include what the API requires.
- 403 Forbidden — Auth worked but the service account lacks permission. Fix on the upstream side.
- SSL handshake failed — Self-signed cert or expired chain. Either fix the cert or (dev only) disable TLS verification.
- Connection timeout — Network/firewall. EmpowerNow's egress IPs may need to be allow-listed.
Test Connection costs nothing and catches 90% of "the workflow doesn't work" issues before you ship a single command.
7 Add your first command
Switch to the Designer tab
The Designer tab is where commands live, organised under object types. An object type is whatever the system is operating on — User, Ticket, Contact, Order. Commands belong to exactly one object type.
- If your Designer is empty, click + Add Object Type. Name it (e.g.
Ticket). It appears as a card. - Inside that card, click + Command. The Enhanced Command Modal opens.
Fill in the command
The modal is YAML-driven, but you don't need to know YAML to use it — there's an Insert Example button that drops a starter template you tweak. The minimum to get a working command:
Click Save command. The modal closes; the command appears in the object-type table on the Designer tab.
mcp.enable: true exposes the command as an MCP tool — AI agents can discover and call it. The ai_use_when hint tells the agent when to reach for this tool. Optional but recommended.
8 Save & test the command
Press Ctrl+S (or click Save System)
Up to this point everything has been local edits. Hit Save System in the top-right of the editor (or Ctrl+S). The platform validates the whole definition, persists it, and the system now appears in the gallery and is callable from workflows.
If another admin edited the same system while you were working, save returns 412 with a Reload / Overwrite dialog. Reload is almost always the right answer — it pulls their latest, you re-apply your delta.
Run the command end-to-end
Click Test in the editor toolbar (or use the per-command Quick Test action in the Designer table). The Test System modal opens:
- Pick the command (
get_ticket_by_id). - Fill in the path/query parameters — for our example, id = a real ticket id.
- Click Run.
- Read the Response tab — status, headers, body. If it failed, the Error tab shows what came back.
{ "id": "TKT-1042", "subject": "Printer offline", "status": "open", "assignee": "alice@corp" }
The system is registered, the connection works, and your first command returns real data. From here every workflow in your tenant can drop this command into a Get-ticket node, and any AI agent with MCP access can call it.
→ What's next
Now that you have one connected system, deepen each layer with the rest of the System Editor guides:
- Systems List — search, filter, paginate, switch between grid/table/tree/mind-map views.
- System Details & YAML Editor — drop into the raw YAML editor, command palette (Ctrl+K), keyboard tab-switching.
- Connection & Authentication — full reference for OAuth, delegation, automation (webhook + poller).
- Commands & Designer — multiple object types, parameter badges, body templates, the Schema Mapper, Fulfillment overrides.
- Testing & API Docs — Quick Test, response shape, browsable API docs tab.