Workflows
/Create and open tenant workflow drafts.
Orbitas
BetaOrbitas helps teams design and run repeatable workflows across people, Vianordis applications, schedules, forms, external systems, and AI-assisted steps. Durable execution, approvals, and event history keep each run understandable and reviewable.
Beta operating manual
Orbitas beta automation manual
Author, publish, approve, monitor, retry, and cancel governed workflows in the Orbitas durable-execution beta.
Audience, scope, and prerequisites
Covers beta authoring, templates, connectors, triggers, publishing, schedules, approval inbox, run inspection, retry/replay/cancel, and administrative controls. Every connector, AI step, and external effect remains subject to tenant policy and explicit authority.
Who this is for
- Workflow authors
- Human approvers and operators
- Orbitas administrators, auditors, and support
Before you sign in
- A tenant-scoped Orbitas role
- A process owner and written success, failure, and rollback criteria
- Approved connector identities and minimum permissions
- Named human approvers for consequential paths
Roles and responsibilities
| Role | Access | Responsibilities |
|---|---|---|
| Author | Create and test workflow drafts and templates within assigned scope. |
|
| Approver or operator | Decide inbox items and monitor or control runs. |
|
| Administrator | Manage connectors, bindings, execution limits, egress, encryption, and governance controls. |
|
Author and publish workflows
Design for retries, duplicate events, partial external effects, approval timeouts, and safe cancellation before publication.
Create a workflow draft
Model trigger, data boundaries, decisions, actions, errors, and completion criteria.
- 1Define the process owner
Record purpose, scope, affected systems, users, data classes, and responsible operator.
- 2Choose a trigger
Use a schedule, form, event, webhook, or application trigger and define deduplication behavior.
- 3Build the graph
Add tasks, decisions, waits, branches, sub-processes, and explicit terminal states.
- 4Configure actions
Use least-privileged connectors and bounded parameters; keep secrets outside workflow fields.
- 5Add failure paths
Define retries, timeout, compensation, human intervention, and non-retryable errors.
- 6Save as draft
Do not publish until test and governance review are complete.
Expected result
A draft represents the entire accountable process, including duplicate, error, timeout, and cancellation behavior.
Test and publish a workflow
Use non-production data and review the exact immutable version before activation.
- 1Bind test connectors
Use sandbox or bounded accounts and synthetic data.
- 2Exercise every branch
Test success, rejection, timeout, retry, external failure, and cancellation.
- 3Inspect run events
Confirm the event journal contains safe metadata and references payload artifacts rather than raw sensitive data.
- 4Complete governance review
Review egress, AI, approvals, limits, schedules, idempotency, and rollback.
- 5Publish the accepted version
Record workflow/version identifiers and activate only approved triggers.
Expected result
One reviewed workflow version is published with approved bindings, triggers, limits, and operator ownership.
Approve and operate workflow runs
A run is an event-sourced process; use its journal and current state before retry, replay, cancellation, or manual intervention.
Review an approval inbox item
Approve or reject only after examining the exact run and proposed effect.
- 1Open the inbox item
Verify tenant, workflow version, run, requester or trigger, and due time.
- 2Inspect prior events
Review inputs, branch decisions, artifacts, connector results, and retries.
- 3Inspect the proposed action
Check target, parameters, data disclosure, financial or external effect, and rollback.
- 4Decide explicitly
Approve, reject, or request correction under the process policy.
- 5Verify continuation
Confirm the run advances or terminates as expected.
Expected result
The approval decision is bounded to one run and exact effect and is retained in its event history.
Inspect and recover a failed run
Choose retry, replay, cancellation, or manual remediation based on known side effects.
- 1Open the run inspector
Review status, ready nodes, timers, events, attempts, artifacts, and connector responses.
- 2Determine external effects
Confirm which actions committed outside Orbitas before changing run state.
- 3Classify the failure
Decide whether it is transient, data-related, authorization-related, logic-related, or unsafe to repeat.
- 4Choose one control
Retry a safe failed step, replay only under the documented semantics, or cancel to stop future work.
- 5Verify and document
Confirm new events and resulting external state and record any manual compensation.
Expected result
The run reaches a known state without duplicating an external effect or losing its audit trail.
Manage a schedule, webhook, or event trigger
Activate only the intended trigger and protect ingress identifiers and secrets.
- 1Open the published workflow
Confirm version and environment before configuring a trigger.
- 2Set trigger scope
Define schedule/time zone or event/webhook identity, validation, rate, and deduplication.
- 3Test with a safe event
Confirm one event creates one expected run.
- 4Monitor initial executions
Review event and run counts for duplicates or missing work.
- 5Disable when no longer needed
Remove unused schedules, webhook access, and connector bindings.
Expected result
The configured trigger produces one authorized run per intended event and can be disabled cleanly.
Security and data handling
- Use least-privileged connector identities and tenant-scoped bindings.
- Keep raw sensitive payloads in approved encrypted artifacts, not event metadata.
- Require human approval for consequential AI and external-system actions.
- Design idempotency and compensation before enabling retries.
- Protect webhook, event, connector, and schedule configuration as privileged access material.
Known limitations
Read before relying on an unsupported workflow
These limits describe the source-pinned Orbitas 0.1.0 beta scope and must be rechecked when the product changes.
- Orbitas is beta and connectors, marketplace items, AI steps, and external platform support vary by release.
- Cancellation prevents future execution but cannot automatically reverse completed external effects.
- Replay and retry semantics depend on workflow and connector idempotency.
- The event journal is append-only operational history and should not contain raw sensitive payloads.
- Administrator controls and elevated roles may require live PAM elevation.
Troubleshooting
You cannot sign in to Orbitas
Likely cause: The session expired, the identity is not assigned to the application, or the tenant claim is missing.
- Open the application from the approved portal and complete sign-in again.
- Confirm that the correct organizational identity and tenant are selected.
- If access is still denied, record the time and request an entitlement check from support.
A documented action or navigation item is not visible
Likely cause: The current role, release, tenant configuration, or feature flag does not expose that operation.
- Confirm the role and prerequisites listed for the procedure.
- Reload the page after signing in again; do not attempt to bypass the interface through direct URLs.
- Ask the product owner whether the feature is enabled for the tenant before reporting a defect.
A saved change or background operation is not visible
Likely cause: Validation failed, processing is still running, or the current view is stale or filtered.
- Review inline validation, status indicators, filters, and the selected tenant or workspace.
- Refresh once and search for the item by its stable name or identifier.
- Do not repeat irreversible or externally visible actions until the original operation status is known.
A workflow produces duplicate runs
Likely cause: Trigger retries, missing idempotency, repeated submission, or event deduplication failure occurred.
- Disable or pause the trigger if safe.
- Preserve event IDs, workflow version, run IDs, and external effects.
- Do not delete journal records; correct deduplication and remediate duplicates explicitly.
A run is waiting indefinitely
Likely cause: Approval, timer, callback, connector, worker, or ready-node projection is blocked.
- Inspect the event journal and current ready nodes/timers.
- Confirm the expected approver, callback, or connector state.
- Use retry, reconcile, or cancel only after identifying external effects.
Contact support
Contact support when
- A repeatable Orbitas error blocks an approved workflow
- Expected data, permissions, or tenant boundaries appear incorrect
- A security, privacy, compliance, or data-loss concern is suspected
- A workflow creates unintended external or duplicate effects
- An approval is bypassed or attributed incorrectly
- Run journal and projected state disagree
Include
- The page, action, and expected result
- The exact error text and time of occurrence, including time zone
- Your tenant, role, browser, and a sanitized record or item identifier
- Whether the problem can be reproduced and which troubleshooting steps were tried
Never include
- Passwords, access tokens, API keys, recovery codes, or session cookies
- Unredacted personal, health, financial, or other regulated data
- Private encryption keys or complete confidential documents unless an approved channel is provided