Learn, contribute, and get useful answers.

Use the documentation for product concepts and operating instructions, the learning paths for guided practice, and the resource library for review checklists and evaluation templates. These materials help a team develop a shared understanding of how it will test, review changes, and preserve evidence.

For an account-specific problem, use customer support so the team can handle organization details privately. For a product suggestion, explain the workflow and the decision you are trying to improve through the feedback channel.

Start with the outcome you expected and the behavior you observed. Identify the product area, deployment type, environment, and whether the behavior is consistent or intermittent. A small, reproducible example is usually more useful than a large dump of application output.

Include what you have already tried and the relevant documentation page. Separate observations from assumptions. If the answer depends on account access or confidential configuration, continue through the private support channel.

Useful contributions include a reproducible documentation correction, a clearer example, an evaluation checklist, an integration use case, or a description of where a workflow becomes difficult. Explain who benefits and how they would judge the improvement.

For a documentation issue, include the page URL, the passage involved, and the behavior or example that needs correction. For an integration suggestion, identify the system, the workflow, required permissions, and the data that would move between services. Avoid promising delivery dates or treating a suggestion as an approved roadmap commitment.

Share only material you have permission to disclose. If your contribution contains third-party content, identify its source and any relevant license or usage conditions. Remove confidential information before submitting it.

Focus on the technical issue, explain assumptions, and give others enough context to respond. Respect different experience levels and accessibility needs. Do not share another person’s contact information, credentials, internal messages, proprietary source code, or private customer data without authorization.

For examples, prefer synthetic data and a minimal test application. Redact tokens, cookies, connection strings, personal information, internal hostnames where sensitive, and identifiers that could reveal customer activity. Review screenshots and logs as carefully as code snippets.

Suspected security vulnerabilities require a private report to security@zof.ai. Follow the vulnerability reporting policy and coordinate disclosure; do not post exploit details or sensitive evidence in public discussions. For an active production issue, follow your organization’s contracted incident escalation process.

After resolving a question, record the context, the change that worked, the evidence used to verify it, and any limits on when the answer applies. Link the relevant documentation and name an owner for updating your internal runbook when the environment changes.

Use a small follow-up exercise to confirm another teammate can repeat the process. This makes support outcomes useful for onboarding and reduces repeated troubleshooting. If the public documentation could explain the issue better, send a focused correction through the feedback channel.