On this page
A successful query needs a named identity
Hypothetical situation: a data engineer creates a OneLake shortcut, queries the data and announces that a receiving team can use it. The team opens its report and sees a different result. The engineer’s test established that one route worked for one identity. It did not establish what every consumer would receive.
Before changing permissions, write down the shortcut path, target path, query engine and identity involved in each test. Keep the person using the report separate from any item owner or configured connection identity. Without those details, ‘access works’ is too broad a statement to diagnose.
This article uses Microsoft’s shortcut-security documentation at its 3 August 2026 repository revision. It is evidence available before the coverage date, rather than a modern page projected backwards. The review exercise deliberately avoids prescribing a new authentication configuration or treating every engine as if it followed the same route.
Before accepting the handover, ask a second authorised reviewer to reproduce one permitted result and one excluded result from the recorded conditions. If they cannot identify the required identity or route, improve the record. A reproducible access check is more useful than an unexplained screenshot, especially when another team must diagnose a changed result after the original engineer has moved on.
Distinguish passthrough from delegated access
The dated documentation describes passthrough and delegated authentication. In passthrough, the user’s identity reaches the target; in delegated access, an intermediate credential is used. It also documents an engine exception: Power BI semantic models using DirectLake over SQL and T-SQL engines configured for Delegated identity mode use the item owner’s identity at the target, with OneLake security roles filtering what the caller can see.
These distinctions matter because removing a consumer’s direct target permission is not an equivalent test across every route. First confirm the actual mode and execution path. Do not infer either from the display name of a shortcut or from the identity that created it.
For the exercise, select an existing, authorised configuration with the data owner. Record its mode without changing it. If the team cannot establish which identity reaches the source, pause the access conclusion and obtain that evidence. Do not compensate by granting wider access to make the demonstration pass.
Test the intended consumer route
Choose approved sample data and representative test identities. Include a permitted consumer and a person who should not see the data. Run the intended consuming route as each identity, recording the expected result before executing the query. A notebook result is useful evidence for that notebook path; do not automatically extend it to a semantic model.
Keep source-side and consumer-side controls separate in the record. The historical documentation describes roles and permissions whose effect depends on the path. This worksheet is not a substitute for the relevant security configuration or a complete grant recipe. Ask the platform owner to confirm applicable item support, roles and engine mode for the environment.
Where a result differs, capture a safe description of the discrepancy. Avoid copying restricted rows into a broadly shared defect ticket. Record the object, identity and route, then have an authorised owner inspect the underlying evidence.
| Test identity | Route and mode | Expected result | Observed evidence |
|---|---|---|---|
| Permitted consumer | Record engine and identity mode | Approved sample is readable | Query result and test date |
| Excluded consumer | Same consuming route | Restricted sample is not disclosed | Denial or filtered result |
| Operational owner | Approved maintenance route | Only agreed maintenance access | Separate maintenance check |
Agree what changes require a retest
An access test is a record of a configuration at a point in time. Identify the changes that invalidate its conclusion: a different target, a changed owner, a new consuming engine or a different authentication mode. Make those triggers part of the handover to the team maintaining the workspace.
Give the information owner a short explanation of the permitted audience and the path used to reach the data. They should not need to interpret an engineer’s personal account as evidence that the intended boundary is correct. Keep the matrix with the operational documentation and assign someone to update it after a material change.
For a practical lab, ask participants to explain two successful reads that use different identities at the target. The learning objective is to state exactly what each result proves. It is not to memorise one permission setting and apply it to every shortcut. That precision helps the receiving team investigate access issues without widening permissions blindly.
Sources & further reading (1)
Historical evidence checked . Review practices and hypothetical exercises are editorial recommendations, not product guarantees.
