A good upgrade is one where nothing happens. On the cross-scope side of Australia, that is precisely the trap. On upgrade day, everything keeps working. The break comes later, the day someone turns the checks on, sometimes without realising that is what they just did.
What cross-scope access protects
ServiceNow isolates applications from one another. A scoped application lives in its own namespace, and code running inside it cannot freely read or write resources owned by another scope. When an operation crosses that boundary, the platform stacks several layers of control.
First, the Application Access settings on the target table, which decide whether other applications may read, create, update or delete records. Then the cross-scope privilege record, in the sys_scope_privilege table, which declares that a source scope is allowed to perform one specific operation against one specific resource in a target scope. Finally, on applications that implement it, Restricted Caller Access, which requires explicit administrator approval before a third-party scope consumes the data.
None of this is new. Cross-scope privileges have existed since scoped applications did, and Restricted Caller Access arrived with London. What changes in Australia is not the mechanism. It is the default.
Two instances, two behaviours
An instance created directly on Australia starts with the stricter cross-scope checks enabled. An instance upgraded from Zurich to Australia keeps them disabled.
The vendor logic is easy to follow: harden new instances, and avoid breaking tens of thousands of existing integrations on upgrade day. The consequence for you is less comfortable. Two instances reporting the same version number can behave differently against exactly the same code.
That is what makes this awkward to diagnose. An integration that passes in one environment can fail in another, or the reverse, with no configuration difference showing up in any update set. The difference is not in the code you shipped. It is in the history of the instance.
The corollary is simple. Nothing breaks on upgrade day. It breaks the day someone enables the checks. And that someone may be an administrator applying a hardening recommendation, a security audit raising the finding, or a freshly provisioned sub-production instance while production stays on its inherited setting.
One table attribute carries the rule
The control sits at table level, through the enforce_dot_walk_cross_scope_access attribute.
// table attribute, per table
enforce_dot_walk_cross_scope_access
// table created before Australia
// add it by hand
// created after
// applied automaticallyTwo practical consequences. First, this is not a global switch: it is set table by table, which rules out handling the topic with a single toggle. Second, your entire pre-Australia table estate is uncovered until someone does the work explicitly.
The important word in the attribute name is dot_walk. That is the part nobody inventories.
Dot-walk is the blind spot
When teams prepare an upgrade, they inventory the integrations that write. It is the natural reflex: a write is visible, it produces a record, it shows up in an audit trail. Indirect reads leave nothing comparable.
A dot-walk is an indirect read, and it crosses tables. An integration querying incident.caller_id.department.manager.email is not reading one table, it is reading four. Each belongs to a scope, and every boundary crossing becomes a check to pass once enforcement is active on the table involved.
A monitoring connector pushing incidents enriched with site name and service owner, an HR feed adding manager data to a request, an export to a reporting tool that flattens three levels of reference: all of these work today without a single cross-scope privilege ever having been declared, because the historical behaviour was permissive. They appear in no inventory, precisely because they have never failed.
Non-standard integrations break first
There is a fairly clear order to what breaks.
Actions and flows built on tables other than incident are exposed first. The standard ITSM core benefits from privileges that ship with the platform and are tested by the vendor. As soon as you move outside that core, to a business table, an extended table or a heavily customised incident model, those declarations no longer exist and you have to write them yourself.
Deeply customised incident implementations follow immediately. An extended incident table with its own references into application tables is functionally a permanent cross-scope integration, even if nobody has ever described it that way.
And there is an asymmetry worth holding on to. Vendor applications declare their privileges in their package and are tested against enforcement, so they surface an explicit error when something is missing. Your own in-house scoped applications have nobody doing that work. They will not warn you.
Four checks before you upgrade
List every integration that reads outside its scope. Not just the ones that write. The fastest starting point is a sweep of sys_scope_privilege to see what is already declared, alongside a review of applications whose Runtime Access Tracking is set to Tracking. Those are the ones where the platform creates privilege records as it goes without ever refusing the operation. The list of automatically created privileges is an inventory of your real cross-scope dependencies, not the ones you planned for.
Know whether each instance was created or upgraded. Production, staging, development, training instances. The answer can differ from one to the next, and that gap is exactly what produces the impossible diagnostics.
Test with the checks on, in sub-production first. Enable enforcement on the relevant tables in a non-production instance, then replay integration paths and ATF suites. Failures surface in the system log as explicit refusals, typically a ScopeAccessNotGrantedException or a message stating an operation was refused due to the table's cross-scope access policy. These messages are workable: they name the source scope, the target resource and the operation. That is your remediation plan.
Pick the date you turn them on. Do not inherit it. This is the most important of the four.
The real subject is control of the calendar
Inheriting a behaviour means accepting that the switch happens at a moment you did not choose, across a surface you have not mapped, usually because of a legitimate hardening action taken by someone who did not know about the dependency.
Choosing the date is the opposite. You inventory, you declare the privileges you need, you test, then you enable during a window when your teams are available.
One note on remediation, because the shortcut is tempting and expensive. The right answer is not to globally disable enforcement to restore permissive behaviour. It is to declare the cross-scope privileges you need, one per operation and per resource, granting only what is actually used. Postponing the hardening only moves the problem to the next upgrade, with a heavier estate and even thinner documentation.
Verify on your own instance
The behaviour described here is observed instance by instance. Before you plan anything, check the state of the attribute on your sensitive tables in your own environments, and read it against the release notes for your Australia patch level. Two instances in your estate may not give you the same answer.
Y. Gassama, founder of Abarys Digital.
Abarys Digital is an independent Moroccan ServiceNow consultancy working nearshore for France and Canada. We run upgrade impact analysis and remediation, alongside your teams or end to end.
Digital intelligence, tailored to you.