ServiceNow Predictive Intelligence Integration Patterns

Common Integration Patterns for Predictive Intelligence

Integration patterns for Predictive Intelligence decide how predictions reach the incident record and how outcome data flows back for training. The sections below cover inbound patterns that consume predictions, outbound patterns that send incident data for model training, bidirectional designs, error handling when the service is unavailable, who owns the integration, and how to design the write-back so a prediction can never overwrite a decision a person has made.

Inbound Patterns: Consuming PI Predictions

Inbound integration pattern means the incident system pulls predictions from PI or receives them as the incident is created. When an incident is submitted, PI estimates how long resolution will take and what category the incident belongs to. The incident system uses these predictions to set priority, assign to the appropriate team, or notify the customer of expected resolution time.

Inbound predictions can be consumed in real-time as incidents are created or batch-processed on historical incidents to backfill predictions. Real-time consumption is most valuable because it drives incident handling decisions as they are being made.

Outbound Patterns: Sending Incident Data to PI

Outbound integration pattern means the incident system exports data to PI for model training. As incidents are resolved, outcome data is sent to PI so the model can learn from actual resolutions. This enables continuous improvement: as more incidents are resolved, PI models become more accurate.

Outbound integration should exclude personally identifiable information or sensitive data from export. Filtering ensures PI receives the information needed for prediction without exposing confidential data.

Bidirectional Integration

Many organisations use bidirectional integration: incidents send outcome data to PI for training, and PI sends predictions back to the incident system for consumption. This pattern keeps the PI model current and improves prediction accuracy over time.

Choosing Between Integration Approaches

Real-time integration provides immediate predictions that can influence incident handling, but requires synchronous API calls and depends on external system availability. Batch integration processes predictions in bulk after incidents are created, reducing dependency on external systems but introducing latency. Hybrid approaches batch-process historical incidents and consume real-time predictions for new incidents.

Error Handling and Failure Scenarios

If PI is unavailable, the incident system should continue to function without predictions. Incidents should still be created, assigned, and handled; the missing prediction should not block workflow progress. When PI becomes available again, predictions should be retrieved for incidents that were created during the outage.

If PI makes an incorrect prediction—assigning an incident to the wrong team, for example—the incident handler should be able to override the prediction. The override should be logged so PI can learn from the incorrect prediction.

Monitoring and Quality Assurance

Prediction accuracy should be monitored. Track how often PI predictions match actual outcomes: were incidents assigned to the right team, were resolution times accurate, were severity assessments correct. If accuracy degrades, retraining might be needed or the model might be making predictions for scenarios it wasn’t trained on.

Ownership of the Integration

The incident management team is responsible for incident handling even if predictions drive decisions. If a prediction causes a problem, the incident team is accountable. This means incident teams must understand how predictions are made, what data they depend on, and when predictions might be unreliable. For example, predictions trained on normal incident patterns might be poor for incidents caused by unusual situations like major outages.

Oblytech’s Predictive Intelligence Integration Services

We design integration patterns appropriate to the organisation’s requirements and technical architecture. Implementation includes data export configuration, prediction consumption configuration, and error handling. We establish monitoring to track prediction accuracy and recommend model retraining if accuracy degrades.

Model Retraining and Continuous Improvement

Predictive Intelligence models should be retrained periodically as new data arrives and business conditions change. Retraining keeps predictions current and accurate. Monitoring model performance over time identifies when retraining is needed.

Model Versioning and Rollback

Predictive Intelligence models should be versioned so if a new model version performs worse than the previous version, the system can rollback. Version management allows gradual rollout of model improvements: deploy a new model to a subset of incidents first, verify performance, then roll out more broadly if successful.

Cross-Functional Ownership

Success with Predictive Intelligence requires collaboration between data science, ITSM, and operations teams. Data science owns the model and training. ITSM owns incident handling and understands what predictions would be valuable. Operations teams provide feedback on prediction accuracy and use.

Mapping which data leaves the record and which predictions come back

Integration design for a prediction model starts with an inventory of data movements, not with the technical pattern. For each piece of data, record its direction, the people or systems allowed to see it, and what breaks if it is missing. The inventory can reveal items that were assumed to be harmless but turn out to be personal, and predictions that were assumed to be reliable but depend on a field that is often blank.

The free-text row deserves particular care. Descriptions can contain names, account numbers and health or employment details that were typed in by accident. Strip or mask them before export, and check the masking on a sample rather than trusting the rule.

Choosing when a prediction is requested

The timing of a prediction decides how much a failure costs. A prediction requested when a record is created can shape the first assignment, which is valuable and fragile. A prediction requested later, such as when a record is updated, is less disruptive but may arrive after a person has already acted. Batch scoring, run on a schedule, is the safest for reporting and the weakest for routing. Choose the timing for each decision separately, because one model may serve several timings.

Designing the write-back so predictions cannot overwrite people

A prediction that writes into a field a person has already set is a quiet source of error. Decide before building whether a suggestion may ever overwrite a value. The safer design writes the suggestion to a separate field or a note, and lets a person copy it into the working field. Where overwriting is unavoidable, only overwrite a field that is still empty, and log every write with the model version that produced it. A suggestion that replaces a person’s choice without a trace is the hardest kind of error to investigate, because nobody remembers making the original choice.

Testing the failure path before the success path

Many integration tests check that a good prediction arrives. Failure paths are the ones that cause incidents, so test them first and in more detail.

1. Make the prediction service unavailable and confirm that records still route through the normal rules without waiting indefinitely.
2. Return a result with a missing field and confirm that the record is still handled and that the gap is recorded.
3. Send a prediction for a record that has since been closed, and confirm that the suggestion is discarded or flagged rather than applied.
4. Update the record after a suggestion has been written, and confirm that the suggestion does not overwrite the later change.
5. Replay a batch of outcomes twice and confirm that the training export does not duplicate them.

Only once the failure paths behave as designed is the success path worth testing in volume, because a volume test on the success path alone will pass even when the failure handling is absent.

Predictions that arrive after the record has moved on

A record can change between the moment a prediction is requested and the moment it returns. The record may have been reassigned, re-prioritized or closed. The integration should compare the record’s state with the state the prediction was built for, and apply the suggestion only where the two still match. Where they do not match, keep the suggestion as a note with its timestamp, so the person working the record can see that it is out of date. Quietly discarding late predictions removes evidence that the timing is wrong, which is information the team needs.

Is a single integration pattern enough for every model?

Rarely. Different decisions have different tolerance for delay and error, so a model that feeds routing and a model that feeds a monthly review often need different patterns, even when they share the same training data.

Who owns a prediction that goes wrong because of the integration?

The team that owns the record’s handling, as the existing rules would also be their responsibility. The integration owner should own the fault analysis, but the handling team must be able to see the suggestion and the reason it was applied or withheld.

What should be logged for every write from a prediction?

The record identifier, the field written, the value, the time, the model version and the state of the record at the moment of writing. That set is enough to reconstruct any decision and to find the cause of a pattern of errors.

How should a retired integration be handled?

Stop the requests first, then remove the write-back, and only then retire the training export. Reversing that order leaves records receiving suggestions from a model that no longer gets fresh training data, which can be a slow way to degrade routing.

Integration work usually touches the workflow engine as well as the data. The action flow designer guide describes what a Flow Designer action is, and the incident management integration patterns describe the integration patterns for incident management. For the wider connection work, the enterprise platform integrations service area covers the wider connection work.