The Ticket Was Approved. Is the Script That Runs Tied to It?

Even in an organisation with mature change management, database work follows this chain: a ticket is opened, the change advisory board (CAB) approves it, a DBA runs a script. There is a silent assumption in the middle: the work that runs is the work that was approved. This article is about where that assumption breaks and how a ticketing integration should close it.

What a Ticket Approves and What It Does Not

A ticket approves the intent: should this be done, when, and who is responsible. The script that will run is usually not in it; what is there is the requester's description. Approval is also a moment, and execution is another. In between, the record may have been withdrawn, cancelled or closed, and the script may have changed. Nobody is lying; the two systems simply cannot see each other.

Verification Has to Happen at Two Points

The first point is when the request is saved. The number is looked up in the ticketing system: does the record exist, is it of the right type, is it closed. A wrong number is caught here, before anyone has spent time.

The second point is the moment of execution, and it matters more. The same ticket is asked again, and that lookup is not answered from a cache, because approval may have been withdrawn after the job was queued. If the change record is not in an executable state, the work does not start. One detail matters here: the stopped job does not die. It stays approved and runs again once the record is ready. Otherwise a temporary state in the ticketing system would behave like a permanent rejection on the database side.

Each Request Type Has a Different Ticket

One rule does not fit every job. A change that runs a script is tied to a change record and CAB approval is required. Extracting data from production is not a change but a request; it is tied to a service request and CAB approval is not required. Emergency approval is usually given afterwards in most organisations, so CAB approval is not required, but the record must still exist and not be closed, and every emergency execution that passes is written down as an exception. A rollback is not new work; it is part of the source change and it should not be locked even if the source record is closed, because blocking the repair of a broken production system is worse.

What the Decision Should Be When the Ticketing System Is Unreachable

This question is usually never asked, and then it is asked at three in the morning. There are two honest answers. The first is to stop the work: safe, but an outage in the ticketing system holds up a fix in production. The second is to continue and record that the check could not be made: speed is kept, but the decision must not stay silent; it has to reach the SOC as an alarm. Which one to choose depends on your risk appetite; what is wrong is that the choice was never made. For emergency requests, the ticketing system should not delay a fire in production.

What to Write to the Ticket and What Not to

If the integration is one directional, the ticket stays in the dark about what happened. The product should write events to the ticket as notes: request opened, approved, executed, failed. But the content of the note is deliberately narrow. Script text, result data and passwords must not go to the ticketing system; ticketing systems are usually read by a broad audience, and an accumulation of personal data or secrets there is a new risk. If a note cannot be sent it must not be lost; the next round should resume from the same place.

Six Questions When Evaluating a Product

1. Is the ticket looked up only when the request is saved, or also at execution?
2. Is the lookup at execution answered from a cache?
3. When work stops on a closed or unapproved record, does the request die or does it run again once the record is ready?
4. While the ticketing system is unreachable, who or which setting decides, and is that decision recorded?
5. Are there separate rules for emergency requests and rollbacks?
6. Can the note written to the ticket contain script text or result data?

The first three questions show whether the integration is really a gate. The last three show whether that gate creates a new risk of its own.

Frequently Asked Questions

Does a ServiceNow or Jira ticket approve the database script?

No. The ticket approves the intent: should this work be done. The script that will run is not in the ticket, and it may have changed after approval or the record may have been closed. That is why the product asks the ticket's state both when the request is saved and at execution, and seals the script's digest separately.

Does database work stop if the ticketing system cannot be reached?

It depends on your choice. There are two policies: stop the work, or continue it while recording that the check could not be made and sending an alarm to the SOC. The default is the second. When the ticketing system cannot be reached, an emergency request always continues and the skipped check is recorded.

What does the product write to the ticketing system?

A short, fixed note for events such as request opened, approved, rejected, scheduled, executed or failed. The note contains no script text, no result data and no password.