Skip to main content

Sandbox environments

Depending on the specifics of your license agreement with Salesforce your organization should have access to Sandbox environments that can be leveraged to facilitate ongoing development and quality assurance activities as new changes are introduced and promoted through your Salesforce environments. Each time a new change is to be made that will be promoted to the Production Salesforce environment it is recommended that a new Sandbox environment be created to ensure all work is being performed within an environment that matches what is available within Production. Customers may also opt to refresh an already existing Sandbox rather than create a new environment to be used.

Determination of whether a sandbox should be created or refreshed is outside the scope of this document and will vary across Customers. Customers are encouraged to reference the Salesforce product documentation for additional information and consideration when leveraging Sandboxes.

Regardless of approach (refresh or create new), the critical point is to ensure work begins in an environment that is representative of the latest and greatest configuration within your production environment. Once a fresh Sandbox is available, a series of steps must be performed to ensure Medical Information Cloud functions correctly and does not interfere with any production environments. The sections below detail the changes recommended for native Medical Information Cloud product capabilities, and will not cover any customizations or additional integrations leveraged in conjunction with Medical Information Cloud.

Sandbox types

Generally, there are three types of sandboxes that are of concern when selecting a type for new Sandboxes:

  • Full Sandboxes will contain full copies of your production data and metadata. These instances will require the least amount of consideration when attempting to reestablish Medical Information Cloud functionality, however, there are typically fewer of these available when compared to the other types.

  • Partial Copy Sandboxes will generally contain your production metadata, but will contain only a portion of the available data. In these cases it is highly recommended that the following objects be copied: All Custom Settings (if available), any object that begins with ‘Loop’ in the API name, & MED_Product__c.

  • Developer Sandboxes will generally contain your production metadata but not any data. As a result, special steps will need to be taken depending on the nature of the change you are attempting to make to restore Medical Information Cloud functionality.

Application configuration

Email deliverability

A new Sandbox can always send emails turned off. To turn this capability back on:

  1. Navigate to Setup > Administer > Email Administrations > Deliverability.

  2. Change Access Level to “All Mail.” Click Save.

Product catalog

A FULL Sandbox refresh will retain all data (i.e. Accounts, Cases, Addresses, Products) from Production. Partial Sandbox refreshes or Developer Sandbox refreshes will NOT. If this is the case, you will need to export the Product records from MED_Product__c and re-import them in your new Sandbox using a Salesforce.com data tool such as Data Loader or Salesforce.com Workbench.

Administrative instructions for the use of these products are outside of the scope of this document.

Note: Depending on the number of products created within your Production environment an administrator could also manually re-create these Products if desired.

Email-to-Case

If your organization is leveraging Email-to-Case in Production, the new Sandbox will retain the Email-to-Case settings from the production org. These need to be removed and replaced with the appropriate settings for the Sandbox.

The steps required to add Email-to-Case records are as follows:

  1. Create an email service address using a valid email, which will create a unique email-to-case email string for email services to your sandbox.

  2. Confirm the email service address by accessing the verification email sent from Salesforce.com to the address you designated, and following the steps provided to validate the address.

  3. Update the corresponding MED_Local_Setting__mdt custom metadata type entries to overwrite the values in the MED_Email2Case_Emails__c field with the new service address created in the previous step.

Microsoft 365™ integration

Komodo Health maintains two Microsoft 365 instances: Microsoft 365 production and Microsoft 365 test. Connect and use the Microsoft 365 production instance in a Medical Information Cloud production environment and the Microsoft 365 test instance in a Medical Information Cloud sandbox environment.

Visit Microsoft 365 configuration to configure Microsoft 365 in your sandbox environment.

Nintex DocGen

Clean Sandbox instances from a Medical Information Cloud Production org should include the installation of Nintex DocGen, the engine used to create snapshots and Fulfillment packages within Medical Information Cloud. The following configuration is needed:

  1. Ensure the Sandbox is authorized by navigating to Setup > Installed Packages > Nintex Doc Gen, and clicking Configure. From the DocGen Admin tab under DOCGEN ADMIN HOME click ‘Authorize Nintex DocGen’.

  2. Ensure the Enterprise Edition of Nintex DocGen is leveraged by navigating to Setup > Installed Packages > Nintex Doc Gen, and clicking Configure. From the DocGen Admin tab under DOCGEN ADMIN HOME > Configuration > Edition ensure ‘Enterprise Enabled’ is selected.

  3. Ensure Document Storage settings accurately reflect the configuration in your production instance. Medical Information Cloud supports both Salesforce Attachments and Salesforce Files as viable options to store documents. Verify the correct document storage is leveraged by navigating to Setup > Installed Packages > Nintex DocGen, and clicking Configure. From the DocGen Admin tab under DOCGEN ADMIN HOME > Configuration > Settings and ensure the Attachment Settings are correct.

  4. Nintex DocGen Packages (DDPs) are the templates used to define and output the various documents sent from Medical Information Cloud. A FULL Sandbox refresh will retain all data (i.e. Accounts, Cases, Addresses, DocGen Packages) from Production. However, Partial Sandbox refreshes or Developer Sandbox refreshes will NOT retain data. If this is the case, you will need to migrate the DocGen Packages from your production environment. For instructions on how to migrate DocGen packages, visit Nintex's documentation.

Veeva Vault

Customers that are leveraging the native Veeva Vault integration will need to make the following configurations to ensure the integration functions as expected:

  1. Update or create the Veeva Vault security policy for users who are to access the Sandbox with the new Salesforce.com Organization ID. Be sure to include the 18-character version of the Salesforce.com ID and NOT the 15-character version. The 18-character version of your Salesforce Organization ID is conveniently available for you to see on the MIC Admin About page.

  2. Ensure the Medical Information Cloud custom setting “Vault URLs” has the appropriate Vault URL added.

  3. Ensure the Remote Site Setting is appropriate for the Vault URL.

Test your Veeva Vault connection by searching and returning documents from a Request.

For details on how to perform the relevant configurations, visit Veeva Vault.

Veeva CRM

Customers that are leveraging the native Veeva CRM integration will need to make the following configurations to ensure the integration functions as expected:

  1. Validate the Veeva CRM connection

  2. Restart the MIRF integration routines

For details on how to perform the relevant configurations, visit Veeva CRM.

Veeva Network

Customers that are leveraging the native Veeva Network integration will need to make the following configurations to ensure the integration functions as expected:

  1. Validate the Veeva Network connection

  2. Restart the DCR integration routines (if applicable)

For details on how to perform the relevant configurations, visit Veeva Network.