Use this link to share with your colleagues:
How to Plan and Test Customizations with a Sandbox: https://help.pm.leapevent.tech/a/1045573
If you're thinking of making a change to the way PatronManager looks or functions, you'll want to test those changes first in a sandbox. A sandbox is just what it sounds like - a playground that works just like PatronManager, but won't affect your data, your coworkers, or your patrons. In this article, we'll focus on how to actually use an existing sandbox. If you haven't set one up yet, check out our "All About Sandboxes" Help article before continuing below.
To help set you up for success, we’ve put guidelines together to help you avoid interfering with PatronManager functionality, corrupting your data, and to prevent negative impacts to your customizations due to PatronManager product upgrades.
Sarah is an office administrator at a the Whoville Orchestra. The Orchestra keeps track of its musicians in PatronManager, but organization seems messy, and Sarah aims to clean it up. Being a diligent administrator, Sarah wants to test her customizations in a sandbox, to make sure they work as intended, before implementing them in her production account - her real PatronManager account.
Let's follow Sarah along through the process!
1. Plan
For any problem, there's ten solutions, and Sarah needs to figure out the best route to take. Is there a recommended app she should install? Maybe a custom field she wants to create? Does she need a new custom object?
First, Sarah lays out the problems at hand - there are several fields that musicians, and only musicians, use. These fields are cluttering up the Patron Contact page layout for everyone else. There's also no reliable way to run a report of all musicians, something her Executive Director would very much appreciate. They also get calls from concert-goers multiple times per week, asking if a certain musicians are willing to take on their children as students.
After some deliberation, Sarah decides to create a new Contact record type called "Musician". She makes a list of all the customizations she plans to make:
- Create new Contact record type called "Musician"
- Create new page layout called "Musician"
- Create a new checkbox field called "Takes Students?", to indicate whether or not this musician is willing to teach students
- Remove all fields related to Musicians ("Takes Students?", "Primary Instrument", "First Hire Date", and "Most Recent Hire Date") from all other Contact page layouts other than the new, Musician Contact page layout
2. Ask
Now that Sarah has a plan, she should get input from her colleagues. Will these changes have unintended consequences for a colleague? Does anyone have additional fields they want to see on the new Musician Contact page layout?
Sarah wants to be sure she's not inadvertently making changes to a part of the system that one of her colleagues use on a day-to-day basis; if she is, she wants to sit down with that coworker and make sure her plans won't disrupt their ability to do their job.
While speaking with the box office, she finds out that musicians are allowed a specific numbers of comp tickets per concert - and the number is different for each musician. The box office has been keeping track of this information on a sticky note, but Sarah thinks it would be better to store the information in PatronManager. She adds "Create a new field, called 'Number of Comp Tix / Concert', to the Musician Contact page layout" to her plan. Great idea, Sarah!
3. Test
Armed with her revised plan, Sarah heads into her sandbox, and makes her desired changes. She wants to test that reports will work as intended, and that all her Contact page layouts will look just right. Sarah also wants to make sure there's no workflows affecting only Patron Contact records that should also affect Musician Contact records.
First things first: Sarah makes sure there's data in the sandbox she can use for her testing. It'd be pretty hard to see what a Musician Contact report might look like if there wasn't a Musician Contact in the sandbox for her to look at, for example. She creates some Musician Contacts and fills in their custom fields.
So how does Sarah know what to test for? It's a lot to think about, so she consults with a checklist:
All Customizations
- Try using your customization as intended. If you've added a new record type, for example, create a new record using that record type. Test that the appropriate page layout has been assigned, and that important fields are available to edit.
- Try breaking your new feature. If you've created a new required field, for example, try saving a record without the field filled in.
- Test how the new feature works in reporting. If you're creating a new object, make sure you can create the types of reports you anticipate using.
- Check your change log and review your past customizations. Will your new project interact with any previous changes, such as workflows or dashboards? If so, do you need to edit these older customizations to be compatible with your new feature?
Apps
- If the app interacts with Ticketing and / or Donations, ensure that it does not disrupt those transactions. Test by making donations or buying tickets from both within the sandbox and online.
- Test how the app works with qualification by purchasing tickets online, making donations online, and signing up to receive marketing emails online.
- If the App does not work well with qualification and/or transactions, do not install the app!
Declarative Lookup Rollup Summaries (DLRS)
- After setting up your DLRS in your sandbox, give your DLRS some time to perform a rollup - usually a day or two is enough time. If your DLRS field is interacting with another formula, rollup, or workflow, the two might create a constant feedback loop. As the creator of the DLRS field, you'll get an error that looks like this:
Apex script unhandled trigger exception by user/organization: 005F0000006ypA8/00DF00000005nHZ
dlrs_ContactTrigger: execution of AfterUpdate
caused by: System.NoAccessException: Entity is not api accessibleEmail Templates
- Send an email to yourself from your new template:
Objects
- Go to a record in your new object, and be sure the page layout appears as intended?
- Look at a record that displays this object as a related list. Check that the columns and sorting in the related list are laid out as intended.
- Create reports you anticipate using to track data within this new object.
Record Types
- Test commonly used reports. For example, a "Mailing List" report, used to create email campaigns, might have a filter to only include Patron Contact Record Types. Be sure your new record type is included on relevant reports.
- Specifically when creating a new Donation Record Type, test your rollup fields. Create new donations with that record type, and see if the "Amount Donated in Last # Days" field updates appropriately.
Workflows
- Both create and edit records to meet the conditions of your workflow, and be sure it fires when intended.
- If your workflow is referencing new records, test how it works for records created by online ticket orders or donations, and how it interacts with qualification.
4. Build
All right! Sarah's customizations are firing on all cylinders. Now it's time to make those same changes in her production account.
Sarah warns her colleagues that she'll be implementing her plan this Friday, from 8 AM to 10 AM. She doesn't anticipate the system, or any specific data, being unavailable during that time, and she makes sure to let them know that. If her customizations were going to interrupt ticket sales, for example, Sarah would want to clear that with the box office team before performing the customizations.
5. Log
Now that Sarah has successfully implemented her customizations, she should record the change in a change log, a history of all the changes that have been made to the Whoville Orchestra PatronManager system over the years. This will help remind her colleagues as to what updates she's made today, and will help Sarah test more efficiently during her next customization.
To read more about change logs, check out our Help article on the topic.