The API call is only an intermediate step
Write workflows use documented interfaces. Activation, validation or downstream processing in the vendor system can still fail. The interface must therefore not mark a task successful merely because an API request was accepted.
The controlled workflow
- Select an individual change: A person chooses the concrete action.
- Review the impact: A preview shows the expected scope based on available data.
- Apply approval policy: Tenant policy and roles determine whether another decision is required.
- Activate in the target system: The adapter executes the documented write.
- Perform read-back: CentaurNexus reads the target state again and only then confirms success.
Failures remain visible
If activation or read-back fails, the task remains open or failed. Audit data records the request, decision, write and result. Teams can distinguish between a requested, transmitted and actually effective change.
Roll back granularly when in doubt
A reversal refers to the selected individual change and confirmed state. This limits the correction and keeps cause and effect traceable.
Why an HTTP success is not enough
Several technical states can exist between an accepted request and an effective configuration. A vendor endpoint can accept the request while downstream validation is still running. Activation can be delayed. An object can be stored before the expected policy order or assignment appears in the readable target state.
CentaurNexus treats these states separately. Requested, approved, sent, activated and confirmed describe different points in the workflow. Operators can therefore see what actually happened instead of inferring complete effect from a green API response.
The individual change remains the decision unit
A policy change starts with a concrete action selected by a person. Examples include an access decision, an update to an existing object or another clearly bounded policy change. Each access decision or policy update remains visible as a separate decision with a clearly bounded target object.
Before activation, the preview shows the available context: affected tenant, target object, current state, intended state, dependencies and available usage information. If historical NSS or LSS data is relevant, its source, data age and coverage travel with the assessment.
Tenant policy defines the decision path
Not every action needs the same approval path. Tenant policy connects risk, role and change type to the intended procedure. A simple action that is already permitted can be handled differently from a change with a broader impact. The important point is that the path is defined before activation and remains visible in the audit trail.
MSP operators can view and change only tenants that are actually within their managed scope. Customer responsibility, executing role and decision are not blurred by a shared operator view.
Read-back compares intended and actual state
After the write, CentaurNexus reads the relevant target state again. The expected result is compared with the target-system response. The workflow moves to confirmed success only when the required attributes match.
Read-back is therefore more than a second API call. It needs a domain expectation: which object should exist, which property should have changed, which status should be active and which tenant is affected? The comparison remains bound to the selected individual change.
What happens when states differ
A mismatch can have several causes. The target system may have rejected the write, activation may still be pending or the returned state may not map clearly to the change. CentaurNexus exposes the mismatch and keeps the workflow in an actionable state. A failed confirmation is not silently converted into success.
The operator can review the task, resolve the cause or roll back granularly when in doubt. The reversal refers to the previously confirmed state and does not broadly affect unrelated changes.
Reviewable handovers for operations and audit
Help desk, administration and security need different details but the same state chain. The help desk needs to know whether a user request is pending or effective. Administrators need the target-object comparison. Security and management need a traceable account of request, decision, execution and outcome.
This shared chain also improves ITSM handovers. Ticket status and target-system status remain separate. A closed ticket is not automatically proof of an effective change; the confirmed target state remains authoritative.
A practical acceptance test
- Choose a bounded test change and define the expected target state.
- Verify roles, tenant policy and any required decision path.
- Execute the write and observe every intermediate state.
- Evaluate read-back against the expected object in the correct tenant.
- Test a deliberately failed or delayed case.
- Trace a granular reversal and its subsequent read-back.
The workflow is ready for daily operations only when both the success and failure paths are understandable. This turns a technical API integration into a controlled operational process.
Measure operations through the state chain
The quality of a change workflow is not captured by the number of closed tasks alone. Useful measures include time from decision to activation, the share confirmed on the first read-back, open mismatches, required reversals and causes of failed executions.
These measures show whether problems arise mainly from unclear requests, missing permissions, vendor validation or technical confirmation. Teams can then improve the adapter, tenant policy or operating instruction at the correct point.
Why activation and audit need the same language
An audit record should contain more than technical codes. It needs to connect the domain object, tenant, deciding role, expected state and confirmed result. Operations and reviewers can then understand the same workflow.
External ITSM statuses also map to this state chain. The mapping prevents closed, resolved and successful from carrying different hidden meanings across systems.
Example: one website approval
A user requests access to a blocked URL. The workflow contains tenant, user, reason, available category and policy context, and the responsible role. After the decision, the adapter writes only the selected change to the target system.
The subsequent read-back checks whether that exact URL or intended object has the expected state. If effect cannot be confirmed, the task remains open. A chat message or closed ticket cannot substitute for this state.
If access is later removed, the workflow refers to the same individual change and previously confirmed state. Other rules and unrelated approvals remain untouched. The path stays understandable for the help desk and security team as well as administrators.
Frequently asked questions
When is a write successful?
Only after the effect has reached the target system and a read-back confirms the expected state.
How does a change remain traceable?
Request, approval, activation and read-back are documented as one connected workflow.
Does every change require dual approval?
No. Tenant policy determines the approval path for each workflow.
Sources and further information
See the workflow in context
Choose the relevant role in the demo launcher. The demo uses prepared sample data.
Open demo launcher