Security, privacy, and billing · how to

Prepare safe evidence for a support request

Build a minimal reproducible support packet with safe identifiers, redacted evidence, and no credentials.

3 min readUpdated August 12, 2026
For
Owner, Admin, Member
Availability
Your current plan and entitlements
Product evidence
WRKZY · reviewed August 12, 2026
Editorial review
WRKZY Editorial
Before you begin
  • The affected feature, workspace slug, and approximate timestamp
  • One safe record identifier and exact visible status or error
  • Permission to disclose the minimum evidence needed for support
  • A redaction method for secrets and unrelated customer data

Evidence should answer six questions

What failed? Where? For whom or what record? When? What state was visible? What safe recovery was already tried? Start with these answers before taking screenshots.

Evidence-led escalation

  1. 01
    ScopeConfirm scope

    Identify the workspace, record, channel, time, and affected users.

  2. 02
    ObserveCheck visible state

    Read the current status instead of repeating the action.

  3. 03
    TraceReview history

    Use delivery events, audit history, or run logs to find the last good step.

  4. 04
    RecoverTry safe recovery

    Retry only when duplication and customer impact are understood.

  5. 05
    EscalateEscalate with redacted evidence

    Share expected versus actual results without secrets or excess customer data.

Confirm scope, inspect current state and history, try one safe recovery, then escalate with redacted evidence.

Build the support packet

  1. State the expected result and actual result in one sentence each.
  2. Record organization/workspace slug and exact route.
  3. Record approximate time, timezone, and first/last occurrence.
  4. Add safe record identifiers: conversation, contact, campaign, automation/run, quote, import, connection, or billing reference as relevant.
  5. Record actor role and whether the problem affects one record, one user, one channel, or the whole workspace.
  6. Capture visible status, published/configuration version, provider reason, and relevant timeline or audit event.
  7. Reproduce once with a marked test record if the action is reversible and non-consequential.
  8. Redact the screenshot and review it at full size.
  9. List recovery steps already tried and their results.

What to include by incident

Evidence by workflow
AreaUseful evidenceExclude
Sign-in/securityUser ID/work email, event/session ID, time, browser, safe audit statePassword, MFA seed/code, cookies, full audit for unrelated users
Channels/deliveryConnection or sender ID, direction, message/campaign ID, provider reason, delivery stateOAuth/Meta tokens, SMTP password, unnecessary message body
AutomationWorkflow/run ID, published version, failed step, receipt state, retry simulationWebhook key, unrelated customer context
Import/CRMImport job ID, file headers, mapping, row number, sanitized sampleFull source file unless explicitly authorized
Quote/billingQuote or organization reference, state, currency, estimate time, provider referenceCard/bank data, buyer verification secrets
AICapability, approximate time, enabled context classes, redacted incorrect claimPrompts or customer content not needed to reproduce

Screenshot sanitization

Crop to the affected control. Remove names, email addresses, phone numbers, message bodies, addresses, commercial terms, and IDs that are not needed. Mask browser tabs and desktop notifications. Keep the route, status label, timestamp, and error when they are material. Re-open the exported image and inspect pixels; a drawn translucent box may not actually remove data.

Reproduction boundaries

Do not resend a message, rerun an import, retry a charge, reconnect a provider, or execute a live automation merely to create evidence until side effects are understood. Prefer status refresh, safe simulation, a test workspace/record, or retained logs.

Transfer and retention

Use the approved support channel. Grant the smallest audience and retain evidence only as long as the incident and policy require. If support asks for broader data, confirm purpose and authorization before providing it.

Final check

Have a second authorized person review high-risk packets. Confirm every attachment belongs to the intended organization and workspace.

Safe support packet
  • Expected and actual result are precise
  • Route, time, scope, role, and safe IDs included
  • One safe reproduction or reason not to reproduce recorded
  • Screenshots inspected after redaction
  • Secrets and unrelated customer data excluded
  • Recovery attempts and current state listed
Was this guide useful?

Choose an answer. No message text or personal information is collected.

Still need help?

Contact WRKZY support with the workspace name and a safe, redacted example.

Contact support about this guide