Skip to content Refresh a sandbox.
Refresh a sandbox.
It comes back ready.
Configuration and secrets, per environment, in one place
Command Center
Import Config Export Config
Configuration ManagementEnvironment ManagementGroup Management
Select Environment
Edit Delete
Configuration: Document Storage
Environment Groups (1)
Development Sandboxes 2 environments
Production (1)
Production
Sandboxes (3)
SIT
Staging
UAT
Document Storage – Production2 environments
Configure values for each field
Edit Delete
Bucket Name
Type: Text
Access Key ID
Type: Text
Region
Type: Text
The reality
Every sandbox refresh costs someone a day
Users come back deactivated
Test users are inactive, every email ends in .invalid, passwords are gone. Someone reactivates them one by one and sends reset links by hand.
Secrets and endpoints are wiped
Named Credentials lose their passwords, External Credentials lose their principals, API keys point at production. Each one is re-entered from a spreadsheet or from memory.
Permissions have to be rebuilt
Profiles, permission sets and public groups for the test team are set up again, in the same order, after every refresh. Miss one and a tester is blocked on Monday morning.
Developers wait on admins
A developer who needs a fresh sandbox files a ticket and waits. The admin has production access, the developer does not, so the setup lands on the admin's desk.
Config scattered everywhere
Values live in Custom Settings, Custom Metadata, Apex classes and spreadsheets. There is no single place to see what each org actually uses, so nothing can be restored in one go.
Wrong values hit production
A test URL reaches production. A stale key survives a refresh. These mistakes happen when environment-specific values are copied by hand instead of assigned per environment.
Every team has the same checklist. Almost nobody has it automated.
Getting started
Three steps, one tab, no code
One managed package in your production org. No servers, no middleware, no vault, nothing for your security team to approve. Set up the same afternoon.
- 1
Install and verify
Install Veles from the AppExchange into production. On the Setup tab, name your integration user, pre-authorise the External Client App and click Verify Configuration. Green means done.
- 2
Connect a sandbox
New Environment, From Sandbox, tick the ones you want. Veles reads them from production, creates the Remote Site Settings on both sides and connects on the first push.
- 3
Assign a workflow
Pick the built-in actions, in your order, and assign the workflow to the sandbox or its group. Turn on refresh detection. The next refresh comes back ready.
Scratch orgs need even less: sf veles setup installs, connects and configures one in a single command. Read the setup guide
What Veles does
Your post-refresh checklist, done for you
Every refresh step, automated
Veles notices when a sandbox refresh completes, pushes the right config and secrets, and runs the workflow you assigned: activate users, fix emails, reset passwords, set profiles and permission sets, restore credentials, run Flows, deploy metadata.
Developers refresh their own sandbox
A developer requests the refresh from their own sandbox. Veles keeps their user, email and access through the copy, then sets the org up. No ticket, no production login.
Built-in actions, your order
Chain the steps a refreshed org needs and assign the workflow to one environment or a whole group. Add your own Apex action for anything specific to you.
One config, every environment
Define a config once with typed fields: Text, Long Text, Number, Boolean, Date, Datetime and secrets. Give Production, each sandbox and each scratch org its own values. Your code reads the right one.
Environment groups
Group environments that share configuration. Define values once at group level, override per environment only where it differs, assign workflows to the whole group.
See every run
Every workflow, step, environment, trigger and duration in the Activity Log, with the error text when something fails. The Hub and the child both keep the record.
Full environment inventory
Every connected org in one list: production, sandboxes, scratch orgs, sub-hubs. Connection status, refresh settings and assigned workflows per environment.
Encrypted export and import
Move configuration between orgs as an AES-256 encrypted, password-protected file. Pick single entries or everything. A failed import rolls back.
Developer API
One line of Apex. The right value. Every time.
veles-apex
btcveles.VelesConfig.forConfig('Mulesoft').getText('API Key');
Typed Apex methods for every data type: Text, Number, Boolean, Date, Datetime
Flow invocable actions for no-code access
Built-in caching so config values are queried once per request
Security & Architecture
Built the Salesforce way
100% on-platform: a managed package, no external servers, no external storage
The only calls are between your own Salesforce orgs, over per-connection tokens
Config and credentials live in protected custom objects nobody can query or export
Values marked hidden are never rendered to the UI, not even to the admin
Locked-down sharing, private by default, admin-only access via a permission set
No shared master secret: each org pair holds its own credential
Safe queries, no injection risk
AES-256 encryption for export and import
Why not just use Custom Metadata or Custom Settings?
Custom Metadata and Custom Settings were not designed to manage environment-specific configuration at scale.
| Capability | Custom Metadata | Custom Settings | Veles |
|---|---|---|---|
| Post-refresh automation | ✕ | ✕ | ✓ |
| User setup after refresh | ✕ | ✕ | ✓ |
| Encrypted export | ✕ | ✕ | ✓ |
| Environment grouping | ✕ | ✕ | ✓ |
| Central UI for config management | ✕ | ✕ | ✓ |
| Flow integration | ✓ | ✕ | ✓ |
| Typed Apex methods | ✕ | ✕ | ✓ |
| Secure migration between orgs | ✕ | ✕ | ✓ |
| Built-in access control | ✕ | ✕ | ✓ |
Building it in-house vs using Veles
If you build this internally, your team owns the encryption, permissions, documentation, and long-term maintenance. Every hour spent building config tooling is an hour not spent on business features.
| Aspect | In-house build | Veles |
|---|---|---|
| Time to build | Weeks to months | Install and configure in hours |
| Security implementation | You design and maintain it | Built-in encryption, private OWD, admin-only access |
| Encryption handling | You build encryption from scratch | AES-256 encryption, built-in and ready |
| Maintenance cost | Ongoing dev time for every change | Managed package, automatic upgrades |
| Upgrade responsibility | Your team handles Salesforce API changes | Package maintainer handles compatibility |
| Documentation | You write and maintain it | Provided and kept up to date |
| Access control | You design permission structure | Permission set, locked-down sharing, admin-only |
| Stays on Salesforce | Depends on your architecture | 100% native, zero external dependencies |
Use cases
Where Veles makes the biggest difference
Integration-heavy organizations
Managing API keys, endpoints, and tokens for Mulesoft, Stripe, Twilio, and other services. One central place for all integration config, with the right value served per environment automatically.
Teams with many sandboxes
Ten developers, ten sandboxes, one post-refresh workflow. Group orgs by purpose, define shared defaults at group level, and let every refresh come back configured without an admin in the loop.
Regulated industries
Financial services, healthcare, and government teams that need encrypted config transfer between orgs, controlled access to sensitive values, and full audit trails.
Developers who want a fresh org today
Request the refresh from your own sandbox, keep your user and access through it, log in to an org that already has its config, credentials and test data. No production login needed.
AppExchange partners (ISVs)
ISVs managing configuration across development, packaging, and subscriber orgs. Keep your package config organized from dev through to customer delivery.
Where Veles Fits
- Nothing leaves Salesforce. Configuration, secrets and logs live in your own orgs. No vault, no server, no third-party account.
- Not a full CI/CD pipeline. Your release tooling keeps shipping code; Veles keeps every org configured, secured and ready after a refresh, and can deploy a metadata package as a workflow step when that is part of the setup.
- Works with the sandboxes and scratch orgs you create today. It refreshes, connects and configures them. Creating them from Veles is on the roadmap.
Veles is the native layer that keeps your orgs safe and ready, with minimal setup.
FAQ
Common questions
Veles polls your production org and notices the refresh completed. It re-links the sandbox, pushes the configuration and secrets that belong to it, and runs the workflows assigned to it or its group: users, emails, passwords, profiles, permission sets, credentials, Flows, metadata. Every step lands in the Activity Log.
Veles runs 100% on Salesforce as a managed package. Config and credentials sit in protected custom objects that nobody in your org can query, report on or export. The only network calls are between your own orgs, each pair with its own token. Hidden values are never shown in the UI. Exports are AES-256 encrypted.
No. No servers, no middleware, no vault, no third-party account for your security team to approve. Install the package in the production org that acts as the Hub and connect your sandboxes and scratch orgs to it.
No. The developer requests the refresh from Veles in their own sandbox. The Hub starts it in production, keeps the developer in a Sandbox Access group so their user and email survive the copy, and runs the setup when the refresh lands.
Yes. Free includes the whole refresh loop: detection, auto-push and workflows after refresh, for 2 connected orgs, 25 config fields, 1 workflow and 1 environment group. Standard and Enterprise are priced per production org, with every user in the org covered.
Not a replacement for your release pipeline. Those tools ship code between orgs. Veles is the native layer underneath: it keeps every org's configuration and secrets safe and gets a refreshed org ready to use, users, access, secrets, configuration, with a metadata deploy as a workflow step when needed. Teams run both.
Custom Metadata has no environment-specific values, no secrets handling, no encrypted export, no grouping and no central UI. Veles has all of that plus typed Apex methods and Flow actions, and it moves the values to the right org for you.