Scoutinternal

Sandbox Test Cases and Aging Notification Tickets in Support Queue

Sandbox Test Cases and Aging Notification Tickets in Support Queue

Problem

Internal sandbox test cases — created to validate Salesforce case automation features such as aging notifications, case assignment, comment notifications, survey triggers, and email-to-case functionality — are generating tickets that flow into the production support queue. These tickets have subjects prefixed with "Sandbox: Case Created" or "Sandbox: New case comment notification" followed by a sandbox case number (e.g., 00001046, 00001089). They are not real customer issues and require no customer-facing action, but they clutter the queue and may confuse agents unfamiliar with the pattern.

Diagnostics

  • Check the ticket subject line: Look for the prefix "Sandbox:" at the start of the subject. Genuine sandbox test tickets will contain phrases like "Sandbox: Case Created", "Sandbox: New case comment notification", or "Re: Sandbox".
  • Check the Salesforce case number: Sandbox case numbers referenced in these tickets are typically low-numbered (e.g., 00001028 through 00001474 in observed samples) and do not correspond to production Salesforce case numbers.
  • Check the ticket subject for test descriptors: Many of these tickets include explicit test language in the subject such as "Test Aging emails", "test aging emails", "Test 1 hour aging email", "Test 2 hour aging", "aging 30 minutes", "1 DAY Case AGING TEST", "3 Day PENDING ENGINEERING FIX Notification", "7 Day PENDING ENGINEERING FIX Notification", "5 day CLOSE test after no actiivty", "Test Trigger", "Outside of business hours test", "testing survey when closed", "TEST Email to Case- Disregard", "test assignment", "Test Trigger", "Vivek Test Case for Appointment Scheduler", or simply "test", "Test", "TEST2", "TEST 3", "test0_0".
  • Check ticket origin: These tickets are created by the same internal automation user (created_by: 158009540847). Confirm the creator ID matches the known sandbox sync automation account.
  • Check for garbled/encoded subject text: Some sandbox test tickets contain corrupted or non-Latin character sequences in the subject (e.g., strings of question marks), indicating test submissions with non-ASCII input or encoding issues in the sandbox-to-production sync pipeline.

Resolution

Scenario: sandbox-case-created-aging#internal-sandbox-test-ticket

Trigger: A ticket appears in the queue with a subject beginning with "Sandbox:" and containing a sandbox case number or explicit test language, created by the internal automation user.

Signals: Sandbox, Case Created, New case comment notification, aging, test, sandbox case number, created_by 158009540847, TEST Email to Case- Disregard

Steps:

  1. Confirm the ticket matches the sandbox pattern: subject starts with "Sandbox:" and/or contains sandbox case numbers (typically 00001xxx) and test descriptors.
  2. Confirm the ticket was created by the internal automation account (created_by: 158009540847).
  3. Do NOT reply to the customer or take any customer-facing action — these are internal test artifacts.
  4. Close or resolve the ticket with an internal note indicating it is a sandbox test case that leaked into the production queue (e.g., "Sandbox test ticket — no action required. Closing.").
  5. If you observe a sudden large batch of these tickets, flag the pattern to the Salesforce administration / Support Operations team so they can investigate whether the sandbox-to-production email routing or case sync is misconfigured.

Notes: These tickets cover a wide range of sandbox test scenarios including: case aging notifications at various intervals (30 minutes, 1 hour, 2 hours, 1 day, 3 day, 5 day, 7 day), case assignment testing, case comment notifications, email-to-case testing, survey-on-close testing, out-of-business-hours triggers, and appointment scheduler testing. Some tickets may appear with garbled non-Latin characters in the subject — these are also sandbox test artifacts and should be handled the same way. None of these require customer communication.

"Sandbox: Case Created - 00001124 - TEST Email to Case- Disregard" (ticket #107145)

"Sandbox: Case Created - 00001125 - 1 DAY Case AGING TEST" (ticket #107169)

"Sandbox: Case Created - 00001048 - Test Aging emails" (ticket #84877)

Scenario: sandbox-case-created-aging#sandbox-access-request

Trigger: A ticket references the sandbox environment but is a genuine customer or partner request for sandbox access rather than an automated test artifact.

Signals: sandbox environment, access to sandbox, Sandbox Environment, sandbox access request

Steps:

  1. Verify the ticket is a real customer request by checking that the subject does NOT start with "Sandbox: Case Created" or "Sandbox: New case comment notification" and that the creator is not the internal automation account.
  2. Treat as a standard sandbox access/environment request. Gather the customer's enterprise name, enterprise owner email address, and the product/service they are interested in.
  3. Follow the standard sandbox or testnet onboarding process (e.g., creating a testnet enterprise). Refer to the existing KB article on testnet setup for guidance.
  4. If the request specifically involves Ethereum testnet (GTETH), direct the customer to the testnet enterprise creation flow and relevant faucet information per standard procedures.

Notes: A small number of tickets in this cluster (e.g., "Access to sandbox environment", "Sandbox Environment", "Re: Sandbox") appear to be legitimate customer inquiries rather than automated test noise. Always verify the ticket creator and subject pattern before closing without action.

Related

  • ethereum-in-testnet — Covers testnet enterprise creation and sandbox access setup procedures referenced in sandbox access requests.
  • none identified for additional directly related articles; the bulk of this cluster is internal test noise rather than a customer-facing product issue.