Get help with the right context¶
When an action fails or its outcome is unclear, keep the original work and identify the step that needs help. A useful support request explains what you attempted, what happened and which organization or item is affected.
Use the support route supplied by your organization or environment. This guide does not invent a support email address, phone number, response-time promise or live status service.
Draft and availability: Support and product journeys retain current implementation limits. Read the relevant feature's recovery guidance; a documented capability is not proof that it is deployed in your environment.
Start with the guide for the failed step¶
The troubleshooting guide connects common symptoms to their owning features. The capability map covers the documented areas when your task is not listed there.
For an uncertain result, do not begin by creating a duplicate account, workspace, request or purchase. Reload or inspect the original item through the supported recovery path and establish what has already completed.
A timeout or error can occur after part of an action saved. A success message can also describe only preparation or a preview. Use the feature guide to understand the actual outcome.
Involve the appropriate owner¶
| Problem | Owner to involve |
|---|---|
| Account activation, sign-in, password or account recovery | The authorized account-support route; use the relevant account guide first |
| Membership, branch, workspace policy or product assignment | The organization's eligible administrator |
| Request, approval, project or other business-work exception | The responsible process or business-item owner, with support where needed |
| Payment, purchased capacity or an unclear commercial change | The organization's commercial owner and authorized billing support |
| Document access, classification or sharing | The source information owner and appropriate administrator |
| Unavailable application or provider connection | The rollout or service owner through the authorized support route |
| Platform incident, export/deletion coordination or privileged recovery | Authorized platform staff using their private procedures |
Read administrator responsibilities, process ownership and platform support for their different boundaries. A support role does not automatically grant authority to approve your organization's work.
Prepare a useful description¶
Include the following information when it is relevant and appropriate for the authorized recipient:
| Information | Why it helps |
|---|---|
| Environment and workspace | Distinguishes where the problem happened |
| Action and affected item | Identifies the actual account, task, document or commercial request |
| Original reference | Helps investigate the existing operation rather than create another |
| Approximate time and timezone | Helps relate the report to retained observations |
| Visible result or message | Distinguishes a denied action, delayed work and an unavailable service |
| What you expected | Explains the business outcome you were trying to achieve |
| What you already checked | Avoids repeating unsuccessful recovery steps |
| Business impact | Identifies the work or people affected without assuming a technical cause |
A short example is: “In the Example workspace, I submitted request EX-104 around 10:15 Africa/Lagos. The page stopped responding. The request is now visible, but I cannot establish whether the review task was created. I have not submitted another copy.”
The example is a suggested support description, not a real incident or a required reference format.
Share information according to the recipient's authority¶
Do not send passwords, one-time activation or verification codes, or browser-session credentials. Avoid including unrelated personal information or confidential document contents in a general support message.
Use an item reference and a description where they are sufficient. If more evidence is needed, confirm the authorized channel and recipient before sharing it. A public forum is not the place for a Support ID, private business record or payment evidence.
An error message is useful evidence, but it does not independently prove which person, provider or component caused the problem.
Understand guided support¶
Guided support is separate from sending a normal help request. The platform-support explanation describes the eligible operator and account boundaries.
Use your Support ID instructions only for the authorized support interaction you intend. The identifier participates in starting guided help; it is not a password and should not be shared publicly.
Refreshing the identifier does not terminate an already active session. The intended End guided help control is not connected in the current profile. Ask the authorized operator to close the session and confirm its end when necessary. An absent banner is not proof that it ended.
Confirm what was resolved¶
After help, verify the outcome that originally mattered. Restored sign-in is not the same as restored membership. A verified payment is not the same as applied capacity. A repaired source does not automatically prove that every dependent report is complete.
Use account and workspace guidance, Billing recovery or the relevant business feature to confirm the result. Keep any remaining work and responsible owner clear.
For a documentation problem, identify the page, section, unclear instruction and the observed difference. State whether the difference concerns wording, unfinished frontend behavior, access or the environment. The availability guide explains why those are separate findings.