Skip to content

Field note

ServiceNow Access Packages: Approval Ownership

The request can start in ServiceNow, but the access decision still needs a clear system of record.

Published17 Oct 2026

Updatedyesterday

Read time4 min. 857 words.

An access request becomes harder to support when the ticket says approved, the identity system says pending and the application still denies access. Adding another portal can make that ambiguity worse unless ownership is settled first.

Microsoft’s 12 October Entra roundup lists ServiceNow integration for access packages as generally available.

It is useful for organisations whose staff already request IT services through ServiceNow, provided both teams understand where the policy lives.

Keep the access policy in its documented home

The integration documentation is explicit: Entra Entitlement Management remains the system of record. ServiceNow provides the request, status and approval experience. Administrators continue to manage packages, policies, eligibility, approvers and assignments in Entra.

Use that division when writing the support model. The ServiceNow team owns the portal integration and its availability. The identity team owns how access is granted and removed. The business resource owner decides who should be eligible and who can authorise access.

Avoid recreating those decisions as a second set of unrelated ticket rules. Otherwise, changing a package can leave the catalogue description promising access that the underlying policy no longer grants.

Before installation, confirm the current integration licensing and follow the installation guide linked from Microsoft’s documentation. Treat the application’s granted permissions and service ownership as reviewable configuration, with a named owner and a record of how updates will be handled.

Start with one understandable package

Choose a low-risk package with a clear purpose, a small requester population and resources whose owners can participate in testing. For example, a time-limited project collaboration package is easier to reason about than “all standard employee access”.

Access-package policies define requester eligibility, approval and lifecycle settings. The package can also contain several resource roles. These details belong in the review alongside the user-facing catalogue text.

Write a short package contract:

  • The work that requires the access.
  • The exact resources and role each assignment provides.
  • The people who can request it.
  • The approver and how absence is handled.
  • The access period and renewal decision.
  • The person responsible for investigating incomplete delivery.

This contract is an operational record, not an extra technical policy engine. Its purpose is to let a manager understand what an approval will cause.

Test the request through to the resource

Do not stop when the ServiceNow form submits successfully. Run one approved request all the way through and have the test user perform the intended task in every included resource.

Keep the request identifier, package and policy identifiers, decision time, assignment state and application result together. This lets the service desk find the relevant layer without repeatedly asking the user to resubmit.

Then test different outcomes: an ineligible requester, a denied request, an approver who is unavailable, and an assignment that expires. Microsoft’s package documentation distinguishes fallback approvers from alternate approvers, so check the configured behaviour rather than assuming that a manager’s holiday automatically redirects a request.

Use a short-lived test assignment to exercise expiry without changing a production user’s access. Check the underlying group or application role afterwards. Portal history alone does not demonstrate that access ended.

Agree which team takes a failed request

A simple routing table prevents an approval problem becoming a long exchange between support queues.

Package is missing from the portalIntegration and identity ownersEligibility and package visibility
Approval has not progressedIdentity governance ownerApplicable policy and approver state
Assignment exists but application failsApplication owner with identity supportResource role and the actual denied operation
Access remains after expiryIdentity and application ownersCurrent assignment and resource membership

Treat this as a starting model and adjust it to the configured integration. Do not promise a delivery time until representative tests and the operational support arrangement justify it.

Have a way to pause new requests

Before wider adoption, document how to stop new requests through the integration while retaining the authoritative assignment records. If a pilot needs to be withdrawn, restore the previous request route and reconcile requests already in progress before users create duplicates.

The longer-term review still matters. A correct initial approval can become stale as projects and responsibilities change. The existing article on guest access reviews covers part of that ongoing ownership.

The integration is ready when a requester can understand the outcome, an approver can understand the access being granted and support can trace delivery or removal. A familiar portal is valuable only when it makes those decisions easier to follow.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?