Secure Vault

The Secure Vault stores the passwords, tokens and e-mail accounts your scenarios need. Values live in the OS keyring of the machine — they are never written into the project file, so a project can be committed to Git and shared with colleagues without leaking credentials.

Each project has its own isolated vault: keys and values are scoped to that project.

Open it with the Vault button in the main toolbar.

📸 Screenshot needed — /img/editor/vault/vault-dialog.png

Capture: the Secure Vault dialog with 4–5 entries of both types listed, showing the Secret Key / Value / Actions columns with values hidden (dots). Annotate: point out the Add, Import Vault and Export Vault buttons. Why it is new: the Vault did not exist in 0.14.2 — this whole page has no screenshots.

---

Using a secret in a scenario

Reference a key with the placeholder syntax:

{{SECRET:MY_KEY}}

Write it into any text parameter — an SQL Password, a Slack Token, a Teams Webhook URL, a command line. The placeholder is resolved at run time and the real value never appears in the project file.

tip

Secrets are resolved wherever plain text is accepted, so {{SECRET:DB_PASSWORD}} works just as well inside a longer connection string as it does on its own in a password field.

---

Managing entries

The dialog lists every key with its value hidden. Per row you can:

Action	Effect
Show / Hide secret value	Reveals the stored value temporarily.
Edit	Opens Edit Secret to change the value or the type.
Copy key	Copies the key name, ready to paste into a {{SECRET:…}} placeholder.
Delete	Removes the entry from the keyring. Asks for confirmation.

Add opens Add Secret, where you give the entry a Key, choose its Type, and fill in the value.

note

A key can be registered with an empty value. It then shows as not yet set — useful when you hand a project to a colleague and want the required keys listed for them to fill in.

---

Entry types

Password

A single string — a password, an API key, a token, a webhook URL.

Field	Description
Key	Name you reference as {{SECRET:KEY}}.
Password	The value. Masked while typing.

Email Account entries

A structured credential for the Email actions. One entry can hold a Receiving (IMAP) half, a Sending (SMTP) half, or both — fill in only the half you need.

📸 Screenshot needed — /img/editor/vault/email-account-entry.png

Capture: the Add Secret dialog with Type: Email Account, both the Receiving (IMAP) and Sending (SMTP) sections visible, Auth method set to Basic, and a successful Test Connection result. Mask: blur the e-mail address and server names; leave password fields empty.

Each half starts with an Auth method:

Auth method	When to use it
Basic (username + password)	Standard IMAP/SMTP with a password or app password.
Outlook OAuth2 (client secret)	Microsoft 365 mailboxes using a registered application.
Exchange (Exchangelib)	On-premise or hybrid Exchange servers.

Basic fields:

Field	Description
Email address	The mailbox address.
Username	Login name — usually the same as the address.
Password	Mailbox password or app-specific password.
Server	IMAP or SMTP host.
Port	Service port. Auto picks the standard port for the protocol.
StartTLS	Upgrades the connection with STARTTLS. (SMTP)
Disable SSL verification	Skips TLS certificate validation. Only for internal servers with self-signed certificates.
Sender name	Friendly From name. (SMTP)
Send-as email	Alternate sender address, for sending on behalf of a shared mailbox. (SMTP)

Outlook OAuth2 fields:

Field	Description
Email address	Mailbox the application acts on.
Client ID	Application (client) ID from your Azure app registration.
Client secret	Secret value of that registration.
Authority URL	OAuth authority, e.g. https://login.microsoftonline.com/common.

Test Connection — or Test IMAP / Test SMTP when both halves are filled in — verifies the credentials before you save, and reports the failure inline if something is wrong.

tip

Test both halves before building the scenario. An authentication problem found here takes a minute to fix; the same problem found during a scheduled run at 03:00 costs a whole night's batch.

---

Import and export

Button	Effect
Export Vault	Writes all keys and their values to a .vault file.
Import Vault	Reads keys and values from a .vault file into the current project's vault.

This is how you move a project to another machine, or to the VM that will run it unattended.

warning

A .vault file contains the secrets in plain text. Treat it exactly like a password list: transfer it over a secure channel, never commit it to Git, and delete it once the import is done.

---

Missing keys

When you open a project whose scenarios reference keys this machine does not have, the Editor tells you which ones are missing before the run fails.

📸 Screenshot needed — /img/editor/vault/missing-keys.png

Capture: the missing-keys dialog listing two or three key names that the project needs but the local vault does not hold.

Fill them in with Add, or bring them over with Import Vault.

---

Good practice

• One key, one purpose. PROD_DB_PASSWORD and TEST_DB_PASSWORD rather than one shared DB_PASSWORD — combined with Enabled (Test) / Enabled (Prod) on the actions, the same scenario then runs safely in both environments.
• Never inline a credential, not even temporarily. A password typed into a parameter is saved into the project file the moment you press Save Project, and stays in the Git history afterwards.
• Reserved keys. Some internal key names are reserved and rejected with a Restricted Key message. Pick a different name.
• The vault is per machine. Keys stored on your workstation do not travel with the project file — the VM that runs the scheduled scenario needs its own copy.