Troubleshooting and escalation

Triage first. Most reports that reach SpaceMedia resolve at one of the first three checks.

Is it permission, or is it broken?

A missing page or a disabled control is usually a role, an add-on, or a feature gate rather than a fault. Check:

1. Does the member have the permission the area requires?
2. Is the add-on that provides it active?
3. Is the organization past demo mode? Before the trial starts, most configuration is read-only and releases cannot be submitted.

Check these before reporting anything, because the answer is visible in your own dashboard.

Is it your side or the store's?

For a delivery question, separate approval from delivery from publication. A release your team approved is not delivered, and a delivered release is not live. See Delivery monitoring.

If a store has the data and has not published, that is the store's schedule, and escalating will not change it.

Is it one customer or all of them?

One customer failing where others succeed points at that account, that release, or that metadata. Everyone failing at the same step points at configuration or the platform. Establish which before escalating, because it changes who needs to look at it.

Escalating to SpaceMedia

Use authenticated Enterprise tickets, so the request carries your organization and permission context.

Include:

• What you expected, and what happened.
• Exact error text, copied.
• A UTC timestamp.
• Public references: release UPC, track ISRC, checkout or payout reference.
• One affected example, not a customer export.
• Whether it affects one customer or all.

Send the minimum that identifies the record. Your customers' data is yours to protect. See Privacy and safe support information.

For integration problems

Add the operation, the environment, the HTTP status, the public request or event reference, and the sanitized error body. Without those an API issue cannot be traced. Reference documentation is at docs.spacemedia.uk.