Sandbox refresh
This is the loop Veles exists for. Set it up once per sandbox, then every refresh ends with a configured org and nobody in the loop.
Before the first refresh
On the Hub, per sandbox (Environment Management, Edit):
- Auto-Detect Refresh: on.
- Run Workflows After Refresh: on.
- The sandbox is in a group that has configuration values and an assigned workflow, or has its own.
- Allow Self-Service Refresh: on, if people inside the sandbox may request its refresh.
- Veles Sandbox Access group: Automatic (Developer and Developer Pro sandboxes) or On (every sandbox type).
And once per Hub: Sandbox Refresh Detection scheduled in Setup > Scheduled Background Jobs. It is off until you schedule it.
Finally, the production integration user must be active and pre-authorised in production; Veles checks that before it starts any refresh and tells you if not.
Request a refresh
From the Hub. Open the sandbox row, find Sandbox Refresh, leave Auto-Activate after Refresh on and click Request Sandbox Refresh. The confirmation lists who will keep access. Veles starts the refresh in production for you.
From the sandbox. A developer or admin logged in to the sandbox opens Veles there, finds Sandbox Refresh on the sandbox's own row and clicks Request Sandbox Refresh. The Hub checks production for who keeps access (up to two minutes), then starts the refresh. The requester is added to the access group automatically. Needs Allow Self-Service Refresh on the Hub's row; otherwise the button says so.
From Salesforce Setup. Also fine. Veles detects any completed refresh, however it was started. The only difference: no Sandbox Access group is prepared, unless you click Prepare now in the group menu on the row first.
Who keeps access: the Sandbox Access group
A sandbox copy deactivates most users and breaks their emails. Veles avoids that for the people who need the sandbox: before the copy it creates a public group in production, Veles_Refresh_<sandbox>_<time>, and Salesforce keeps its members active with their real email in the new sandbox. Members are:
- users named in Activate Users actions of the assigned workflows,
- User Setup rows with Activate on, when the workflow includes User Setup,
- the post-refresh integration user,
- the person who requested the refresh.
Veles removes the group once it detects the refresh, or after 7 days if the refresh never completes. It never touches groups it did not create. The group menu on the row offers Prepare now, Rebuild and Remove.
What happens when the refresh completes
- Detection. The hourly job sees the completed refresh on the production. To check sooner, open the production row and click Check for refreshes now (it looks back 7 days).
- Re-link. The sandbox has a new org id; Veles stamps it on the row and reconnects. On the sandbox side, the first Veles activity clears old synced data, including every User Setup row.
- Push. Configuration, secrets, workflows and User Setup rows go to the sandbox.
- Workflows. Every workflow assigned to the sandbox or its groups runs, in order, as trigger After refresh. Users come back active with fixed emails, passwords, profiles and permission sets; credentials get their secrets; Flows and metadata run.
Inside the sandbox, the Setup tab shows Setup After Refresh running and ends with a toast like Setup After Refresh completed. Workflows after the refresh: 2 ran.
See it
Activity Log on the Hub shows one Sandbox Refresh row for the request, the detection, the Config Push and each workflow run with trigger After refresh, step by step. The sandbox shows the same from its side. A step that failed says why in its message; fix the cause and run the workflow again from the sandbox row with Run.
If nothing happened after a refresh
In this order: is Sandbox Refresh Detection scheduled, does the sandbox row have Auto-Detect Refresh on and a Production Environment set, does the production row show a recent Last checked, does the production's integration user still sign in (Check again). Then Troubleshooting.