Platform / Dev Dashboard

Function run log details are now
shown automatically "as long as you have the right access scopes"

No more asking the merchant to "please share the logs" every time. If your app holds the required scopes, the function run log details in the Dev Dashboard appear automatically.

What's on this page
  1. The gist in 30 seconds: what changed
  2. How it works: scopes hold the key
  3. Before vs. new behavior
  4. Three patterns of scope requirements
  5. Troubleshooting steps
  6. Key points for developers
  7. Three practical use cases
  8. A one-line summary for your pitch

1The gist in 30 seconds: what changed

On the Dev Dashboard, the "details" view of the Function run log has shifted from manual sharing by the merchant
to automatic determination based on "the access scopes your app holds" .
If you satisfy the required scopes, you can see the details right away.

Before: ask the merchant

To view function run details, the merchant had to perform a "share" action. The app developer's workflow was request-based.

New behavior: automatic determination by scopes

If your app can read, via the GraphQL Admin API, the scopes that the function's input query requires, the details appear automatically.

2How it works: scopes hold the key

Function The input query declares the fields it reads Determine the required scopes read_orders read_customers read_products ... Check against the app's scopes Does the app hold them? Are all required scopes satisfied? Dev Dashboard display ✓ Details appear automatically ✗ Details are hidden After the scopes are granted, they take effect on the next access
The basis for the determination is the function's input query. The fields the query reads mechanically determine "which scopes are required to view this log."
= The permission to view logs and the permission for that same function to actually read data in production areMatched by the same rule .

3Before vs. new spec comparison

ItemBeforeNew spec (this change)
Conditions for viewing log details Manual An action the merchant shares Automatic Determined by the app's access scopes
Determination criteria Not documented (merchant's discretion) the function's input query scopes it requires
Merchant request Required each time Not required
When it takes effect — After the required scopes are granted, on the next access it's shown automatically
Where it's displayed Dev Dashboard Dev Dashboard (same)

4Three scope request patterns

When the required scopes aren't present, the documentation lists three ways to obtain them. Choose the one that fits your use case.

Common

1. Request at install time

Scopes the app needs permanently. Declare them in the install/auth flow.
Use case : Fields always required for standard operation.

Protected data

2. Protected customer data

Customer details, addresses, etc. require an additional approval process —they're protected data. Request data-level scopes separately as well.

Optional

3. Optional scopes

For temporary needs like debugging, use an optional scope.
Merchants can grant/revoke without reinstalling.

5Steps to check when troubleshooting

1

Check the input query

Identify the fields read by the function's input query.

2

Match against required scopes

Check whether the app holds the scopes required to read those fields via the Admin GraphQL API.

3

Request what's missing

Choose the best option among the three paths—standard, protected data, or optional—and obtain the scope.

Once the scope is granted,the details are shown automatically the next time you access the log . No additional steps such as reinstalling are needed (for optional scopes).

6Key points for developers

1. The permission basis is unified around the "input query"

The logic for whether logs can be viewed is derived from the function's input query. In other words, "the permission to read data in production" and "the information visible in logs" follow the same rule.

2. Customer data requires separate approval

Items such as customer details / addresses additionally require the protected customer data approval process and data-level scopes. Design them separately from general scopes.

3. For debugging, optional scopes are the way to go

For scopes you don't need permanently but want to see only during incidents, request them as optional. Since merchants can grant or revoke them without reinstalling, the operational burden is low.

4. Changes take effect on next access

A granted scope takes effect "the next time you access the log." There is no mention of immediate-refresh behavior. Watch for this timing difference when running reproduction tests.

OK NG

5. Before assuming "logs aren't visible = a bug," suspect the scopes

When the expected details don't appear, the correct order is to first suspect not the function but the app's scope declaration . Re-read the input query and check whether the corresponding scopes are present in the app's manifest—this usually resolves it.

7Three use cases you can apply at work

!
USE CASE 1

Improving the "incident response flow" for apps that include a Shopify Function

Problem
Behavioral anomalies in the function that occur only in the merchant's environment required asking "please share your logs" every time and waiting for a reply before investigating.
Approach
Declare the scopes required for production fully and precisely at install time. Prepare debugging-purpose scopes as optional scopes.
Result
Check input/output instantly from the Dev Dashboard with zero requests to the merchant → drastically shorten MTTR.
Technical note
Take inventory of the fields the input query reads and align the corresponding scopes in the app manifest. Don't forget protected customer data approval for customer-related data.
USE CASE 2

A "scope validity review" practice before App Store submission

Problem
When submitting an app that includes a function, requesting too many or too few scopes causes trouble in review and operations. The basis for the decision was unclear.
Approach
Attach a "list of required scopes" derived backward from the function's input query to the submission documentation.Log details being shown automatically = the necessary and sufficient scopes are in place —add this as a review criterion.
Impact
You cut down on over-requesting (improving the privacy impression) while also preventing post-launch "we can't see the logs" incidents.
Technical notes
Note that if the input contains fields classified as protected customer data, a separate approval process—distinct from the regular request—is required.
debug optional prod required
USE CASE 3

Designing a "debug-only" optional scope to lower operational overhead

Problem
You routinely request stronger scopes for incident investigation, so merchants push back with "too many permissions" or you get flagged in a privacy audit.
Approach
Keep production requests to the minimum, and what's needed only during investigation should be declared as an optional scope. Make it an SOP to ask the merchant to "grant it temporarily" when a support ticket is filed.
Impact
Minimize standing permissions while still ensuring the needed details are visible in the Dev Dashboard during investigation. You can also revoke them afterward.
Technical notes
Optional scopes can be granted or revoked by merchants without reinstalling. You can boil it down to a routine: start a debug session → request the grant → analyze → revoke.

8One-line summary you can use in a proposal

"Detailed access to the Function run log is now automatically determined by access scopes .
You can debug with zero merchant requests, and you just work the required scopes backward from the function's input query.
Everyday use at install / customer data as protected / debugging as optional — maintain least privilege across these three tiers."