Four ITSM paths for existing processes
CentaurNexus connects ServiceNow, Jira Service Management, Freshservice and Zendesk through real adapters. Each task remains assigned to the correct tenant and customer context. Request, status, decision and result can be connected without manually copying identifiers between interfaces.
Outbound notifications for Teams and Slack
The webhooks initially send outbound notifications only. The event catalogue covers approval requests and decisions, policy changes, new incidents, revoked sessions and accepted consent. Each tenant and channel defines which events it actually receives.
In daily operations, the help desk can see a new approval request, Security receives notice of a policy change, and operations is informed about a new incident or a revoked session. The notification carries the relevant tenant, task type, current status and a direct path to the matching CentaurNexus context. The teams responsible for the next step therefore receive the same reliable operational picture without rebuilding it from separate systems.
Target-system status remains authoritative
An ITSM ticket or chat message is not evidence that a change took effect. In write workflows, CentaurNexus confirms success only after target-system effect and read-back. The ITSM system receives a reliable status rather than a message that an API request was merely started.
Keep the MSP context
MSP access remains limited to tenants that are actually managed. Tickets, events and audit records retain the correct tenant context. Responsibility and handovers therefore remain traceable.
What belongs in an ITSM case
An integration is useful only when it passes more than a link. A well-formed case connects a plain-language summary with tenant, user or object context, source, current status and the next responsible role. Raw technical data is not copied indiscriminately into the ticket. The operator receives the context needed for the task and a controlled path back to the complete CentaurNexus record.
The external ticket ID and internal workflow ID remain linked. Status updates can therefore be assigned without mixing customer or tenant contexts. The audit trail records which handover occurred and when.
A help desk workflow from report to resolution
A user might start a request for a blocked website in the browser. CentaurNexus adds the permitted user, device and policy context. The designated ITSM system receives a structured case. The help desk can review the initial finding, add missing information and decide whether to resolve, approve or hand the case to a specialist role.
If a controlled change follows, ticket status and technical execution remain separate. The ticket can show that activation is running. The effective state is reported only after confirmed read-back. If the workflow fails, teams can see whether the cause lies in the decision path, adapter, activation or read-back.
Notifications complement the case
Teams and Slack are useful for concise signals to the responsible group. A message can draw attention to a new decision or changed status. The full reason, sensitive detail and binding action remain in the intended CentaurNexus or ITSM context.
Technically, CentaurNexus posts to an incoming-webhook address configured by the tenant for the selected service. From the CentaurNexus perspective, the data flow is outbound. Channel, event selection and destination therefore belong to tenant configuration rather than a global cross-customer distributor.
Responsibility during failures and retries
An unavailable ITSM service or rejected webhook must not turn the underlying Zscaler workflow into a false success or failure. Integration delivery has its own status. The platform can distinguish a successful domain action from a notification that still needs attention.
Acceptance testing must also cover retries. A technical retry must not create uncontrolled duplicate tickets or contradictory messages. Idempotent assignment, external IDs and visible delivery state are therefore part of the integration contract.
Different ITSM systems, one domain contract
ServiceNow, Jira Service Management, Freshservice and Zendesk have different object models, permissions and status logic. The adapter translates these differences into a shared CentaurNexus workflow without ignoring the target system's own model.
An incident in one system can differ from a service request in another. Each customer therefore defines which case type supports each CentaurNexus workflow. Required fields, attachments, comments and closure states are not treated as universally identical.
Manage secrets and destinations by tenant
Credentials for ITSM adapters and webhook addresses do not belong in public website configuration or visible ticket text. They are read at runtime from the intended secret path and remain assigned to the tenant. Logs and error messages must not expose the values.
Teams and Slack channels accept only permitted HTTPS destinations. A test message verifies the channel without creating a domain event. Changes to destination, event selection or active status remain traceable.
Privacy in handovers
Not every technical detail from user, device or feed context belongs in an external ticket or chat channel. The field mapping defines what is necessary for the purpose. Deeper context remains in CentaurNexus and opens through an authorised link.
International organisations also review region, language and recipient scope. A notification should reach the responsible operator without spreading sensitive content through broad team channels.
Operating responsibility remains visible
The integration connects systems but does not silently move responsibility. The ITSM team owns its forms, queues and status logic. The CentaurNexus administrator owns tenant mapping, roles and adapter configuration. The domain decision remains with the role assigned by the workflow.
Each adapter has technical and domain contacts. During an incident, teams can distinguish a CentaurNexus workflow issue from an external API, permission or destination-channel problem.
What a daily integration review checks
Operations reviews failed deliveries, unusually long open handovers, unmatched external IDs and channels with recurring errors. Domain workflow state remains separate from technical delivery state.
A short review prevents a successful target-system change from being overlooked because a message failed, or a closed ticket from hiding an effect that is still unconfirmed. Trends across repeated failures also reveal where field mappings, permissions or destination ownership need a planned correction rather than another manual workaround. The result feeds the next service review.
Introduce the integration in seven steps
- Choose the leading ITSM system and concrete case types for each tenant.
- Map fields, statuses, roles and responsibility boundaries.
- Configure authentication and the least required permissions.
- Test tenant and customer assignment in both systems.
- Configure Teams or Slack channels with selected events.
- Accept success, failure and retry paths under controlled conditions.
- Review read-back and final ticket status together.
The goal is not another parallel portal. CentaurNexus connects technical Zscaler context with the place where support and operations already manage their work.
Frequently asked questions
Which ITSM systems are connected?
ServiceNow, Jira Service Management, Freshservice and Zendesk.
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