About Salto: Salto's platform helps you and your team deploy, track, and manage your NetSuite customizations effortlessly. Learn more here.

‍

Introduction

NetSuite Sandbox environments are an essential piece of the NetSuite development life cycle. The ability to build and test in an environment separate from Production is not only best practice but is mandated for many NetSuite customers.

Despite going through this process several times per year (hopefully), NetSuite Teams still make mistakes with regards to their refresh procedures. In this article, we will explore eight common mistakes that are made when refreshing your NetSuite Sandbox.

‍

Mistake 1 - Not refreshing your Sandbox consistently

It is important to refresh your NetSuite Sandbox on a predictable, consistent basis. This sets the right expectations with all users impacted by a refresh and will ensure the NetSuite Administration team do not delay a refresh due to other priorities.

Having the latest and greatest data and customizations in your Sandbox environment is essential for testing new solutions. Without this, testing could be successful in Sandbox, but the solution fails after migration to Production due to the numerous differences between the two NetSuite environments. The longer a Sandbox refresh is delayed, the more the environment will differ from Production and therefore increase the risk of solutions failing in Production despite successful testing in Sandbox. 

When your Sandbox refresh is on a consistent cadence—quarterly perhaps—it allows for the syncing of refresh calendars across applications upstream and downstream of NetSuite. For NetSuite customers using a different CRM, it would be ideal to synchronize the Sandbox refresh calendar across both applications. That way, any development that spans both systems can be performed and tested in environments that were refreshed around the same time.

‍

Mistake 2 - Not timing your Sandbox refresh correctly

When you request a Sandbox refresh, NetSuite does not take an immediate snapshot of your Production account at that point in time. Instead, when the request is made NetSuite will look for the latest snapshot taken of the Production environment. This will typically be from the previous night or early morning hours. Experience tells us that the snapshot timing can vary, so it is best to request a Sandbox refresh the day after the day on which you need the Production snapshot.

In some cases, you may not care so much about a 24 hour difference in the Production data and configuration, but in others this will be critical. Imagine you have just rolled out a large customization to Production today and are looking to refresh your Sandbox as soon as possible to allow for new customization work to begin. In this case, it would be best to wait until the following day to request the Sandbox refresh to ensure the new customization is included in the Production snapshot. If not, you will be starting your newly refreshed Sandbox environment with a big disparity from functionality available in the Production environment. Not ideal.

‍

Mistake 3 - Granting access to users manually post refresh

After a Sandbox refresh has been successfully requested, performed, and applied, the next step is to re-grant user access as quickly as possible (among other things) to minimize the impact on operations.

One way to help expedite this process is to take a backup of all users and user roles from the Sandbox account prior to the refresh request. This can then be manipulated in a CSV file for quick import following the refresh. This can be done for users with multiple roles.

Salto Tip: If your users access Production via SSO and Sandbox is not configured for SSO, don’t forget to remove the role permission “SAML Single Sign-on” from these user roles in Sandbox so that users can log in without running into authentication issues.

‍

Mistake 4 - Losing in-flight development work

It is critical that you back up any in-flight development work prior to activating the Sandbox refresh. The last thing a NetSuite Administrator or Developer needs is to realize that the project they were working on in Sandbox is now gone forever and they need to rebuild the solution. You can argue that the development work should be backed up in other ways (e.g. SuiteScripts backed up to a repository such as GitLab), but that is not so straightforward for other NetSuite objects.

To avoid this painful situation, make sure to confirm with your NetSuite team that all in-flight development work has been backed up and can be retrieved post refresh.

‍

Mistake 5 - Lack of communication

Communicating planned Sandbox refreshes is absolutely essential. Just look at the mistakes we have already discussed. Some could be avoided with simple communication sent in advance.

Ideally, there would be an initial communication around two weeks prior to the planned refresh, a follow up one week prior, and a final communication after the Sandbox has been refreshed successfully. This will give the NetSuite Administration team plenty of notice to back up their work and expedite development and/or testing where required.

In addition to the advanced warning, it is important to consider the audience for these notifications. They should be sent to the core NetSuite team as well as power users. Power users may be in the middle of testing a solution and will need to be aware of refresh plans.

You will see in the following mistake that it’s also important to share these notifications with whomever is managing inbound and outbound integrations for NetSuite.

Salto Tip: For anyone partnering with external consultants for NetSuite development work, don’t forget to inform your consultants of the refresh schedule for the same reasons it is important to inform your internal NetSuite team.

‍

Mistake 6 - Forgetting to review your integrations

Following a Sandbox refresh you need to give thought to every integration in your Production environment to determine whether they need to be recreated in Sandbox.

Access tokens will need to be created. Navigate: Setup > Users/Roles > Access Tokens > New

For any custom solutions that have Production credentials included in the refreshed Sandbox, these should be removed/updated as soon as possible so that Sandbox activity has no impact on external Production systems. It is important to complete this step prior to granting user access to the Sandbox.

This is also the reason team members managing integrations to and from NetSuite need to be involved in the process and given plenty of notice. Post refresh, integration tokens will need to be recreated in NetSuite and updated in both upstream and downstream applications.

For any banking credentials stored securely in Production, these should be removed entirely from the refreshed Sandbox environment to eliminate any risk of test transactions being processed through existing  banking integrations.

‍

Mistake 7 - Allowing different authentication methods for users

We touched briefly on this mistake earlier. If you are not leveraging SSO for your Sandbox environment you will need to remove the SSO role permission from user roles in Sandbox post refresh, so that users can authenticate via email address and password.

‍

‍

If you have your Sandbox configured for SSO authentication you shouldn’t need to update the existing user role permissions. Users will be able to authenticate in the same way they access Production today.

SSO is not available for highly privileged roles, e.g. Administrator. As a result, NetSuite Administrators who are testing in Sandbox and need to switch between the Administrator role and end user roles struggle with the constant authentication requests. One way around this is to create a copy of the SSO roles and, within the copied roles, go ahead and remove the SSO permission. Now when Administrators access these roles in Sandbox, they can do so without switching authentication methods, which makes for a seamless testing experience. 

‍

Mistake 8 - Not updating references to Production

Another area that gets overlooked after a Sandbox refresh is performed relates to specific Production references, primarily URLs. 

Have you ever clicked on one of your Sandbox homepage shortcuts only to be taken to the NetSuite login page? That’s because your shortcuts reference the Production URLs and you are not currently logged into that environment. Post refresh, take a minute to update all of your shortcut URLs to save on future headaches. This will need to be done by each user.

Another area to pay close attention to is that of hardcoded URLs in NetSuite custom form solutions, e.g. Advanced PDFs. A common use case to consider is a payment link URL on a customer invoice. Solutions such as these will not dynamically update URLs to remove the reference to Production environments and must be updated/removed in Sandbox, otherwise you run the risk of users accessing live Production URLs from test records created in Sandbox. 

‍

Best Practices for refreshing your NetSuite Sandbox

1. Perform your NetSuite Sandbox refreshes on a consistent schedule. Delaying Sandbox refreshes can impact Production deployments as testing could be validated in an “old” Sandbox environment but fail in Production as a result of too many discrepancies between the test (Sandbox) and Production environments. These environments will diverge as time goes by.
2. Time your NetSuite Sandbox refresh correctly. When requested, the Sandbox refresh will look for the latest snapshot of your Production environment, typically from the previous night. It is not always at midnight local time, so if you want to ensure that the most recent production deployments are captured (e.g. deployed same day) it is best to wait until the next day to request a Sandbox refresh.
3. Extract users and roles prior to performing a NetSuite Sandbox refresh so that you can reestablish user access to the Sandbox environment shortly after the refresh has been applied. This can be done in a matter of minutes with a quick CSV import.
4. Back up any in-flight development work prior to activating the Sandbox refresh, otherwise you will lose that development work. It is best to confirm with your NetSuite Administrators and Developers prior to activation.
5. Be sure to communicate the timing of a planned Sandbox refresh with plenty of advanced warning. Even if development work is accounted for, users may be testing with Sandbox data and therefore lose that testing  if they are not made aware of the refresh timing. As a best practice, consider a formal notice two weeks prior, one week prior, and shortly after the refresh has been successfully performed.
6. Review and update your integrations to/from NetSuite as required. You may run into issues if the NetSuite Sandbox refresh includes Production credentials for a particular customization and runs the risk of impacting Production accounts inside or outside of NetSuite. Plan to remove the Production credentials or replace them with test environment credentials. This is typically required after a Sandbox refresh.
7. Create non-SSO user roles so that Administrators can test in the Sandbox environment efficiently, without the need to switch between non-SSO and SSO user roles for testing. This was mentioned under the mistakes tied to NetSuite user roles & permissions but is worth reiterating here.
8. Update any hardcoded URLs in NetSuite solutions that reference Production URLs to instead reference a Sandbox URL or remove them entirely. This is more prevalent in user shortcuts and objects such as advanced PDFs that may include a hyperlink to an external third party software (Production).
9. Automate some of the standard Sandbox refresh tasks automatically by leveraging a custom SuiteScript that can be manually triggered following a Sandbox refresh. While this will take some time to build and test on your next refresh cycle, it can save time and effort if the same tasks are repeated after each refresh.
10. Create a Sandbox refresh checklist. Some of the mistakes we reviewed in this article should be included in the checklist. Every environment will have different objects and records that need to be updated. Also consider using these best practices as a starting point to form your own NetSuite Sandbox refresh checklist.

‍

For more information on these best practices, check out Salto’s blog post that explores some of the things NetSuite Developers and NetSuite Administrators should consider when refreshing the NetSuite Sandbox. By following these best practices, you can manage your environment refresh process efficiently and effectively.

‍

‍

Final thoughts

Sandbox refreshes are a very common practice for NetSuite customers, which is why it is important to establish a Sandbox refresh checklist and ensure nothing is missed during the refresh process. When executed successfully, a Sandbox refresh should not be viewed as an administrative burden but instead as a means to support robust testing of new functionality and customizations.

Communication pre refresh and swift action post refresh will make for a smooth process all around. Think about leveraging the above best practices as a starting point for your own Sandbox refresh checklist if you don’t have one already or to challenge your existing checklist.