Ticket validation for access requests
Requiring an open Jira or ServiceNow ticket before an access request can be created, resolved per organisation against your own connected instance, and what happens if you turn this on with nothing connected.
Master Policy's Ticket control requires a validated, open ticket before an access request against a safe can even be created — not just a text field the requester fills in, but a live check against a real, connected ticketing system. It is one of the seven Master Policy controls, on the base policy form at Privileged → Policies, /pam/policies.
It validates against your organisation's own connected instance
Ticket validation is resolved per organisation: whichever Jira or ServiceNow instance you have connected through the integration catalog is what a request is checked against, using that connection's own credentials, decrypted only for the moment of the check. There is no shared, platform-wide ticketing system standing in for this — connect your own from The connector catalog.
- Jira — validated against the ticket's
statusCategory(a workflow-agnostic classification every custom Jira workflow status maps onto, so a project with a non-standard "Done"-equivalent status still resolves correctly). - ServiceNow — validated against the built-in incident state values for closed. A heavily customised ServiceNow state model is a stated limitation here — an instance using non-standard closed states may not be read correctly.
- Freshservice — connected as a ticketing/notification destination elsewhere in the product, but is not yet a supported ticket-validation source for this control.
A missing ticket, a ticket that does not exist, or one that is already closed all refuse the request the same way: the request is never created.
What happens if you turn this on with nothing connected
The practical implication: connect Jira or ServiceNow before turning this control on, not after — otherwise you will lock out access to the safe the moment you save the policy, until a ticketing system is connected.
Supplying a ticket on the request
The access-request form carries an optional ticket system and reference field — optional because the form has no way to know in advance whether a given safe's policy requires one. An approver reviewing the request sees the ticket system, the reference, and the state the platform recorded for it at the time the request was validated.
What to read next
- Master Policy and its exceptions — the other six org-wide controls this sits alongside.
- Access requests and approvals — the request this control gates.
- The connector catalog — connecting Jira or ServiceNow.