Sandbox Considerations

Salesforce sandboxes are a great way to test apps and are often essential (or required) when implementing new functionality. While Salesforce is great and flexible in providing many Sandboxes, odds are you really only have 1 MS Teams environment.

In this page, we hope to help you navigate through this and set you up for success as you work your way to Production.

Building in a Sandbox

After installing our package, the next step will be to create a Salesforce Site. We recommend having a site “Default Web Address” in Sandboxes that you will also use in Production. For example, use MSTeams and not MSTeamsSandbox. 

We recommend this for 2 reasons:

  1. The URL will contain the sandbox name, and having it in the Default Web Address is redundant.
  2. Assuming you deploy to Production, a refresh will change the Default Web Address.

Next, you’ll be creating the Bot in Microsoft Teams. As you (likely) only have 1 Teams environment, you will need to decide if you want to have a Bot for each Sandbox or if you will just have 1 Bot. You can add multiple Bots to our application in Salesforce, however in Microsoft Teams a Bot can only point at a single Sandbox (for sending Channel details when a Bot is added to or removed from a Team).

If you plan to only have 1 bot, you can configure the Bot’s endpoint address to point to the Sandbox for now, and then when you deploy and configure our solution in Production you can edit the Bot’s endpoint address to point to Production.

Refreshing a Sandbox

When a Sandbox is refreshed, you will want to adjust your Sandbox Template to copy over Teams Bots and Teams Channels.

The Site, and your Flows are Metadata and copied over automatically. Flows are built and saved using IDs that come from Microsoft for your Teams and Channels. 

As a result, testing on records in a refreshed Sandbox will also cause the notifications to be sent to your destinations as if they were coming from Production.

If you want to have different behaviors between Production and Sandbox, you’ll need to build that into your Flows.

Environment Aware Flows

To make your Flow aware and behave differently in Production VS a Sandbox, you’ll need to add a couple of elements.

  • Environment Details -> Retrieve details about the Org, such as if it is a sandbox and its name.
  • Decision Element -> Create different paths based on the Flow running in any sandbox, a certain sandbox, or in Production.
  • Environment specific Teams actions -> You can mix and match here as your needs dictate. Send a notification into a Group Chat in Production, but maybe send into a Testing Channel when in a Sandbox.

Now let’s say you really want to keep notifications created in a Sandbox sent through a “Testing” bot to a “Testing” channel, and in Production you want to have your notifications sent normally. 

In your Sandbox, you will register both Testing and Production Bots, though you will only configure the Endpoint Address for the Testing bot. Having both Bots added to Salesforce allows you to select the Bot & Channel in your Flow.