A full Salesforce sandbox is intended to be used as a testing environment and is a replica of your Salesforce production org. However, Fastcall will not replicate from your sbox to your production org. A unique Twilio subaccount will be created in production and this cannot conflict with a sbox. If you are installing Fastcall for the first time in the sbox, the Twilio subaccount created will be unique. If you installed Fastcall in production first, and the sbox is a clone of production, the Twilio connection will be the same as production. Which is fine for basic testing. If you need a unique Twilio connection you will need to uninstall Fastcall from the sbox and install a clean version of Fastcall. This will create a unique Twilio subaccount.
Installation Method
Fastcall is no longer installed from the AppExchange for Sandboxes or Developer Orgs. Instead, it is installed via a direct installation link. Please contact our support team to request the most up-to-date installation URL for your testing environment.
Twilio Subaccounts and Phone Numbers
If you already have an existing Twilio subaccount created by Fastcall (for example, from your Production org), you can safely connect your Sandbox to this same subaccount. It is completely supported.
The Golden Rule for Phone Numbers: Shared, but not Used Simultaneously
Because the subaccount is shared, you will be able to see your Production phone numbers inside your Sandbox. This is completely normal. However, you must only use a specific phone number in one org at a time. Actively using (routing calls with) a Production phone number inside a Sandbox will cause immediate webhook conflicts and disrupt your live Production routing. To test safely, you must provision a new, separate test number that will be used exclusively in your Sandbox.
Alternatively, if you prefer not to incur the cost of provisioning additional numbers, you can release a phone number from one org and import it into the other.
New Installations (No existing account)
If you do not have Fastcall installed in Production yet and therefore do not have a Twilio subaccount, you can connect to a shared testing account during the setup process to evaluate the application. Alternatively, if you prefer, Fastcall can create a dedicated Twilio subaccount for you at this stage (please note that any associated Twilio usage costs will be invoiced).
Cloning Environments (Full / Partial sandboxes)
If you are creating a Sandbox that is a clone of your Production environment, the existing Production Twilio connection will be copied over by default. Since sharing the subaccount is supported, this connection is safe to keep. However, before running any tests, you must ensure you provision a separate test number (or import an unused one) and verify that no Production numbers are assigned to routing elements in the Sandbox.
Sandbox Org Limitations
When testing Fastcall in a Sandbox, please keep the following Salesforce and operational limitations in mind:
Performance Differences: Salesforce Sandboxes operate on different server tiers and are inherently slower than Production orgs. You may experience slight UI or processing latency that is not representative of your live Production performance.
Email Deliverability: By default, Salesforce restricts email deliverability in Sandboxes. If you are testing features like Voicemail notifications or Missed Call emails, ensure you update the Deliverability settings in Salesforce (Setup > Email Administration > Deliverability) to “All email”.
API and Storage Limits: Depending on your Sandbox type (Developer, Partial, or Full), you have significantly lower data storage and API limits. Heavy load testing can easily exceed these limits and cause operations to fail.
Support Scope: Fastcall fully supports initial setup and basic testing in Sandbox environments. However, our primary support SLA and active troubleshooting efforts are strictly focused on your live Production org. Debugging complex, custom Sandbox development falls outside of standard support.