How it fits together
Six words carry the whole product. Read this once and the rest of the docs will make sense.
Hub
The production org where Veles is installed and where you work. The Hub stores configurations and workflows, knows every connected org, detects sandbox refreshes and runs the automation. One Hub per company is the normal shape. On Enterprise a Hub can report to another Hub (a sub-hub), for subsidiaries or regions that manage their own orgs.
Environment
One connected Salesforce org, shown as a row in Environment Management. Four types:
| Type | What it is | How it connects |
|---|---|---|
| Production | The Hub itself, or another production org | Hub is created at setup; another production connects from its own Setup tab |
| Sandbox | A sandbox of a production the Hub knows | New Environment on the Hub, then sf veles setup or the sandbox's own Setup tab |
| Scratch org | A scratch org of your Dev Hub | sf veles setup from the command line |
| Sub-hub | A production running its own Veles that reports to this Hub | Its Setup tab, This org reports to a Master Hub |
Every environment shows its connection state as a pill. Sandboxes can be refreshed from Veles and are watched for refreshes.
Environment group
A named set of environments that share configuration and workflows, for example All sandboxes, QA or Developer orgs. An environment can belong to several groups in priority order; the first group that has a value wins, and the environment can override any field itself.
Configuration
A named set of typed fields: Text, Long Text, Number, Checkbox, Date, Date/Time, each optionally a secret (Masked, Protected or Credential). Payment_Gateway with Endpoint URL, API Key and Timeout is one configuration with three fields. Values are set per environment or per group. Code reads them with btcveles.Veles.forConfig('Payment_Gateway').getText('Endpoint URL') or a Flow action, and always gets the value for the org it runs in.
Workflow
An ordered list of actions that Veles runs on an environment: activate users, fix emails, reset passwords, update profiles, manage permissions, manage credentials, run a Flow, deploy metadata, or your own Apex action. You assign a workflow to an environment or a group. It runs when you click Execute Workflow, automatically after a refresh when Run Workflows After Refresh is on, or when a scratch org first connects.
Push and pull
Push sends configuration values, workflows and User Setup rows from the Hub to a child. Pull is the same transfer started from the child. After a refresh the Hub pushes on its own. Secrets travel encrypted between your own orgs and nowhere else.
The refresh loop, in one paragraph
Someone refreshes a sandbox, from Salesforce Setup or from Veles. Within the hour (once refresh detection is on in Setup) the Hub notices the refresh completed, re-links the sandbox under its new org id, pushes its configuration and secrets, and runs the workflows assigned to it and its groups. Users who were in the sandbox's Veles Sandbox Access group keep their access and real email. The whole run, step by step, is in Activity Log.
