- Who is this for?
- CIOs, security teams, operations leaders and process owners
- Question addressed
- Prepare the data and permissions required to deploy a first Vigilo workflow.
Key takeaways
- Access is defined per workflow step, not per entire application.
- Reading, preparing, writing, approving and administering are distinct permissions.
- Every action should remain linked to its source, the rule used and the observed outcome.
- A missing permission, ambiguous data or an impossible check must stop processing cleanly.
Start with a complete loop, not every available data source
Consider a first scope: process time-slot change requests received by email for one transport type, prepare the TMS update and submit cases received less than 24 hours ahead to operations. The workflow must also verify that the final saved value matches the decision.
This scenario requires a few precise sources. It requires neither the company’s full history nor an administrator account in the TMS. Scoping means connecting every step to the minimum data, minimum permission and expected evidence.
The scenario’s minimum sources
| Source | Useful data | Why it is needed | Boundary to define |
|---|---|---|---|
| Dedicated mailbox or queue | Sender, recipients, timestamp, subject, body and authorized attachments. | Detect the request and retain its original wording. | Covered folders, labels, senders and retention period. |
| TMS | Reference, customer, current slot, status and fields of the relevant transport. | Link the request and know the state before action. | Accessible entities, transport types, fields and screens. |
| Rules repository | 24-hour rule, scope, version, owner and exceptions. | Determine whether approval is mandatory. | Only active, approved rules may be executed. |
| Availability source | Slots or constraints actually used by the team. | Avoid proposing an unavailable value. | Read access limited to pilot sites and periods. |
| File history | Events, decisions, approvals and outcomes within scope. | Explain the current state and avoid a conflicting update. | Access limited to the context required by the workflow. |
A step-by-step permission matrix
| Step | Minimum permission | Denied by default | Expected stop |
|---|---|---|---|
| Observe the email | Read the in-scope queue and attachments. | Browse other mailboxes or send a message. | Out-of-scope source, unreadable attachment or unknown type. |
| Link the file | Search and read the required TMS fields. | View unrelated entities or files. | No reliable match or several plausible matches. |
| Apply the rule | Read the active version and its exceptions. | Create, modify or activate a rule. | Missing, expired, conflicting or out-of-scope rule. |
| Prepare the change | Build a proposal without writing. | Change the real state of the file. | Missing required data or unverifiable slot. |
| Obtain approval | Present context and receive an authorized decision. | Bypass the required approver. | Rejection, no decision or unauthorized identity. |
| Update the TMS | Write only authorized fields on the targeted file. | Delete the file, change other fields or extend scope. | Invalid session, unexpected screen or concurrently changed value. |
| Verify the outcome | Read the state again and compare it with the expected result. | Treat a click as proof of success. | Missing, different or unreadable value. |
Reading, preparing and acting do not carry the same responsibility
These levels can coexist in one workflow. A standard change may be authorized while a late request remains supervised. The permission should follow the nature of the decision, not a global notion of “autonomy” granted to the application.
- 01Observation
Vigilo reconstructs the file and logs what it would have proposed without changing systems.
- 02Preparation
Vigilo fills a proposal that the operator reviews and submits.
- 03Supervised execution
A person approves the precise action before it is executed.
- 04Authorized execution
Vigilo acts independently only for cases covered by active rules, permissions and checks.
What the log must let a reviewer reconstruct
Logging does not mean copying every available data point. The log should support explanation, control and resolution, with retention and access rules appropriate to the sensitivity of the information.
- the triggering event, its source and timestamp;
- the selected file and, where relevant, the candidates that were rejected;
- the values read, their origin and the version used for the decision;
- the applied rule, its status and version;
- the proposal produced and any human approval;
- the technical identity that performed the action and the permission used;
- the state before action, the expected state and the state actually read back;
- the reason for a stop, handoff or correction.
API or interface: the same control requirements
When an API exposes the required action and control level, it generally provides a structured route. When the workflow must use a screen, access follows the same principles: a dedicated account where possible, limited roles, a validated environment, authorized fields and result read-back.
UI interaction makes it possible to adapt to heterogeneous TMSs and tools, but it does not remove the need for scoping and testing. A changed screen, unexpected dialog or expired session must be detected as a stop reason, not worked around unpredictably.
Stops to define before the pilot
| Stop family | Example | Useful handoff |
|---|---|---|
| Identity | Two transports match the reference in the email. | Present candidates and the facts that distinguish them. |
| Data | The new slot is absent or contradictory. | Request the missing value with the rest of the file prepared. |
| Rule | The request is late but no active rule covers this customer. | Hand off the decision and flag the missing rule. |
| Permission | The account may read the file but cannot change the slot. | Retain the proposal and notify the workflow owner. |
| Interface | The TMS shows an unexpected step or field. | Suspend writing and attach the observed state. |
| Verification | The read-back value differs from the submitted value. | Mark the action as unconfirmed and hand off both states. |
First-scope checklist
- a clearly named triggering event and expected outcome;
- a business owner and a technical owner;
- included sources, entities and periods;
- accounts and roles limited to scope;
- active rules, their versions and exceptions;
- steps that require human approval;
- checks before and after each action;
- stop reasons and handoff recipients;
- logging, retention and access to logs;
- criteria for remaining in observation or authorizing another step.
Frequently asked questions
Direct answers
Does Vigilo need an administrator account?
Not by default. Roles should be limited to the reads and actions of the workflow. Any exceptional need should be justified, tested and governed separately.
Must Vigilo copy all TMS data?
No. The workflow accesses the data required for its context and checks within the agreed scope. Retention and access rules should be defined with the company.
Can a deployment start in read-only mode?
Yes. An observation phase can measure matching, proposed decisions and stop reasons before any write is authorized.
What happens when the TMS interface changes?
The change should be detected by the journey checks. The action is suspended until the affected component is validated or adapted.
Do the same permissions work for every workflow?
No. Sources, fields, rules and risks differ. Permissions are defined for each workflow and environment.
Sources and methodology
This resource describes Axonovia's product approach based on transport workflows. The examples are illustrative and do not constitute a performance commitment or a universally applicable contractual rule.
Product review: Axonovia team · next review recommended before 31 August 2027 or following a material change in scope.