In Rhythm, your customer is your organization’s Rhythm account. It brings together the environments where your data and settings live: your live account and, if you have them, one or more sandboxes. Everything you do in the Console happens in one environment at a time, including each record you open, query you run, and setting you save.
Why It Matters
Most “missing” data confusion happens when you are working in a different environment than you expected. If a link, page, or record looks wrong, check which environment you are signed in to before you assume something is broken. A record in your live account does not exist in your sandbox until the sandbox is refreshed, while a new sandbox starts with a copy of your live account’s data from the moment it was created. Changes you make in a sandbox never affect live data, and sandbox changes, including source-code changes, are not automatically added to your live account. Because of that, you may still need to check behavior separately in each environment. Once you know where you are and how your environments relate, those differences make sense.
Configuration or setup you build while testing in a sandbox, such as a new membership type, does not move to your live account. When testing is done, you need to recreate that setup there. Test data works the same way in reverse: anything you create directly in your live account stays there, even if you created it only to try something out. Support cannot remove that data for you, so use a sandbox for anything you are only testing.
Treat sandbox data as unstable for another reason, too. Because a sandbox is not your live account, Rhythm may change or update its data in bulk without notice, separate from any refresh you request.
Customers and Their Environments
| Term | What it is |
|---|---|
| Customer | Your organization’s Rhythm account. It groups every environment that belongs to you. |
| Live account | Your main production environment, with your real members, orders, and settings. Its identifier is usually the same as your customer identifier, which is also the domain string used to refer to that environment in API and environment references. |
| Sandbox | A separate environment for testing configuration, new features, and training without affecting live data. Rhythm creates sandboxes when you ask for one; not every customer has one. |
Rhythm also gives each environment a type: customer, sandbox, demo, training, or support. That type tells Rhythm which environment is your live account, which ones are sandboxes, and which ones Rhythm uses for demonstrations or training. An environment has the customer type unless Rhythm sets another type. A demo environment is generated from a template environment, so its behavior, including whether a particular application opens correctly, can depend on the template used to create it.
A sandbox can be set up with or without the member portal. A sandbox without the portal is enough for testing renewals, certifications, memberships, billing runs, and most other configuration. A sandbox with the member portal enabled can take longer and may need engineering help, depending on its size and scope. If the portal is not enabled, test account-creation flows in the Console instead of the portal; the flow still works, just not through member-facing pages. A portal-enabled sandbox for testing your directory or other member-facing content is not always available right away, because it depends on review and setup by Rhythm beyond a standard request.
A separate environment is usually not the right way to represent a subdivision of your organization. Sandboxes are for testing, not for splitting one organization’s live data into pieces. Manage subdivisions within your live account instead.
Some capabilities, such as support for multiple currencies, are turned on for your account at the environment level before their setup appears in the product. For multi-currency, that setup then appears in Finance & Billing.
Which Environments You Can Use
In the Console, you see only the environments you can use. When an administrator sets up a Console user, they choose which of your organization’s environments that person can access. Access is set individually in Security Settings on each person’s user profile, so a staff member must add access for each person who needs it.
If you cannot see an environment you expect, such as a newly created sandbox, your administrator has not added it to your access yet. Ask your administrator to add it in Security Settings on your user profile.
If an old sandbox or training environment still appears in the environment dropdown after it has been disabled, clear your browser cookies and check again. The list can hold onto browser-side state after your access changes.
When an account is closing, administrative access and member access do not always end at the same time. Rhythm may need to disable the environment separately so members can no longer sign in, even after Console access has stopped.
Where You Land When You Sign In
When you sign in, Rhythm opens one environment without asking:
- the environment whose identifier matches your organization’s customer identifier, normally your live account, if you can use it;
- otherwise, the first environment you can use;
- if you cannot use any of your organization’s environments, Rhythm tells you no environment is available.
If your access includes only a sandbox, you land in that sandbox. See Sign In and Choose Your Account.
One Environment per Session
Your session is tied to the environment you are working in. Rhythm refuses any request that points to a different environment than the one tied to your session. To work in another environment, switch environments in the Console; see Switch to Another Account or Sandbox. If you see an Unauthorized error right after switching, your session is still tied to the previous environment.
How a Sandbox Refresh Works
Rhythm refreshes a sandbox by copying data from a source environment, usually your live account, into the sandbox. When you ask for the refresh, tell Rhythm the purpose of the test and which application areas need to reflect production, so the request can be scoped correctly. Rhythm submits the request to engineering, runs the refresh, and then emails the person who asked when it is done. There is no set turnaround time because it depends on engineering’s other work. You can also ask Rhythm to remove a sandbox you no longer need. Like a refresh, removal is something Rhythm does for you, not something you do yourself.
flowchart LR
A[Refresh requested] --> B[For each included area: clear the sandbox's data, then copy in the source data]
B --> C[Switch off copied scheduled query emails]
C --> D[Republish portal pages, menus, and assets]
D --> E[Completion email]
E --> F[Search and other derived data are rebuilt]
What a refresh does:
- It replaces, it does not merge. For each included area, Rhythm clears the sandbox’s records first, then copies in the source environment’s records. Anything you built in those areas in the sandbox is replaced.
- Copied records become the sandbox's own. After the refresh, those records belong to the sandbox, and changing them never affects live data.
- Scheduled query emails are switched off. Rhythm does not copy scheduled query deliveries. If the copied data includes an active saved-query email delivery, Rhythm switches it off so the sandbox does not email your members on your live schedule. Other scheduled processing is not necessarily switched off.
- Portal content is republished when that content is included, so the sandbox portal shows the refreshed pages, menus, and assets. If you request a refresh without portal content, the sandbox portal stays as it was.
- Search catches up afterwards. The completion email arrives while search and other derived data are still being rebuilt, so search in the sandbox can be empty or out of date for a while.
- Console configuration comes along too. A refresh is expected to include the latest configuration from the source environment, such as custom fields and related setup, not only records.
What a refresh does not copy:
- sign-in and user security data;
- integration settings and credentials;
- scheduled query deliveries;
- the sandbox’s own portal settings;
- recurring processes and certain system and versioned data.
Those areas keep whatever the sandbox already had, so they can look older than the refreshed data. Historical snapshot reporting does not run in sandboxes at all, whether or not you refreshed recently.
A refresh of an environment with a large amount of data, heavy customization, or portal components can need more lead time because it takes more work to complete successfully. If part of the refresh fails, engineering may need to validate and fix that part before the sandbox is handed back for testing.
Warning
If a refresh fails partway, some areas can stay empty in the sandbox until the next successful refresh. The person who requested it receives a failure email, though occasionally that email has been sent even though the refresh actually completed, so check the sandbox itself if that seems wrong. A refresh can also fail outright with an error saying the target is not recognized as a valid sandbox of the expected source, or it can fail because of an underlying product issue that needs an engineering fix before it can run again. After a refresh finishes, an individual record can still show an error such as RecordNotFound if it points to something the copy did not bring along cleanly. A sandbox’s portal sign-in can also stop working after a refresh because portal-related settings are not always carried over cleanly. Contact Support if members can no longer sign in to the sandbox portal after a refresh.
A refresh is not always possible to complete on an existing sandbox. If the refresh path is not workable, Rhythm may need to create a new sandbox for you instead. The same is true if a temporary problem affects refreshes generally. When a portal is not needed, creating a new Console-only environment to replace an existing sandbox or training environment is a reasonable substitute until refreshes are working again.
A few other things can look wrong after a refresh, or in a sandbox generally, and usually have a straightforward explanation:
- Setup that exists only in your live account, such as default batch settings, is not always present in a sandbox. A configuration error in a sandbox that does not happen in production can come from that difference rather than a mistake in your setup.
- A sandbox created from a template can occasionally inherit contact-form settings that no longer apply, which appears as an “unable to determine form” error when you create a contact. Contact Support if a brand-new sandbox behaves this way.
- A sandbox can show an “id already exists” error during an action such as cancelling a membership application. This is usually caused by the sandbox’s own record-numbering rather than anything you did, and the action may still complete despite the error.
- If an action like that keeps failing in one sandbox because of this kind of error, creating a new sandbox has sometimes let the same testing succeed.
- If a sandbox is missing setup data needed for a test, such as a configuration record added only after the last refresh, you can add it manually in the sandbox, use another sandbox if you have one, or perform that step directly in your live account instead of waiting for a new refresh.
- If a sandbox shows unexpectedly limited navigation or application access, it may be an incomplete or stale copy. Ask Rhythm to re-clone it.
- If order counts or revenue in a sandbox’s reports look far higher than expected after a refresh or copy, treat it as a possible sandbox data anomaly rather than real activity. Compare against your live account and contact Support if it does not resolve itself.
Sandboxes and Email
A sandbox is meant to be safe for testing, including email. Set up the sandbox’s email redirection so messages go to your test inboxes instead of members; see Email Settings: Senders, Reply-To, Footer, and Sandbox Redirects. A sandbox is not a reliable stand-in for testing payments because it is not connected to a live payment processor, and its email confirmations can differ from what your live account sends. For that kind of testing, live is usually the better environment.
Sandboxes and Domains
If your sandbox address is under one of Rhythm’s own domains, you do not need to do any DNS work because Rhythm sets up that DNS. Portal and microsite domains that use your own domain are covered in Set Up Your Domains: The DNS Worksheet.
A Console-only sandbox is usually quick to provide because it does not need domain work. A sandbox with a member portal is more involved because the portal needs its own domain configuration. Rhythm may make the sandbox’s Console usable for testing before its portal setup is finished.
If a new environment is taking a while to become available, Rhythm may be waiting on information or action from you, such as completing the DNS steps above, rather than being delayed on its side.
During a Platform-Wide Outage
If delays or errors affect many people at once, such as during an AWS service disruption, check Rhythm’s public status page for real-time updates. You can subscribe there to receive email updates until the incident is resolved.
Common Questions
I found a record in the sandbox that is missing in live. Can it be copied back? A refresh copies from the source environment into the sandbox. It does not copy sandbox records back into your live account. If a record was deleted from your live account, staff can look up the record in a sandbox that has not been refreshed since the deletion and use it as a reference to manually recreate the record in your live account. The sandbox copy is only as current as its last refresh. The same approach can help after an incorrect merge: an older, unrefreshed sandbox may still have the separate contact details that were merged away, so you can re-enter them on a replacement profile.
The sandbox is missing recent data. It shows live data as of its last refresh. If you have more than one sandbox, each one is refreshed separately, so check that you are signed in to the sandbox that was refreshed.
What is a sandbox good for? Use it for anything you would do in your live account but want to try first, such as new configuration, forms, or workflows. That includes correcting a payment applied to the wrong invoice, reversing a payment, or creating a debit or credit transaction. You test against a recent copy of your data without affecting live data.
How do I know when my sandbox was created or last refreshed? That information is not currently shown to administrators in the Console. Ask Rhythm if you need to confirm it.
Why didn't Support just fix or test this directly? Support needs your permission before making changes or testing in your environment, so they may ask you to reproduce the steps yourself first.
My account is closing. Can I get my data first? Ask Rhythm whether your Console access can be temporarily restored so you can retrieve data yourself. This is decided case by case, and a full export is often handled as a separate process. See A File Will Not Upload, Open, or Download for how exports are delivered.