Credential management

Almost all automation needs access to systems that require a username and password: an ERP, a mail server, an API, a database. The problem is obvious: you should not write those passwords inside the playbook. If you do, anyone with access to the project sees them, they remain in the logs and changing them requires re-editing the automation.

Zoan Cloud credentials solve this. They store sensitive data encrypted within an environment, and your bots retrieve it at runtime by name, without the actual value ever appearing in the playbook or logs.

Idea central

On the playbook you write = credential("erp-produccion"), not the password. The actual value is safely injected by the agent right upon execution. Changing the password is updating the credential in the portal — the playbook is not touched.

Create a credential

1. Enter the environment and open the Credentials tab.
2. Click New Credential.
3. Give it a unique and descriptive name (e.g. erp-produccion, smtp-notificaciones, gmail-api). This is the name by which you will reference it.
4. Add the data that the credential needs (see the two formats below).
5. Guarda.

Dos formatos de credencial

Unique value

For a simple secret, such as a token or a single password. You recover it with .ToPlainText().

Field	Value
value	sk-prod-9f2a...

Multiple fields (key-value)

For systems that require multiple data together. Each field is retrieved by its key with ["campo"]. For example, a database connection:

Key	Value
host	db.miempresa.com
user	nexus_user
password	••••••••
database	produccion

Values are not displayed again

Once saved, the values are encrypted and cannot be viewed from the portal — replace only. This protects secrets even from whoever administers Zoan Cloud. Save the original value in your password manager if you need to keep it.

Service account key (Google)

For server-to-server authentication (e.g. a Google service account), store the full JSON key —exactly as downloaded from Google Cloud— as the single value of a credential. The activity references it by name and builds the authentication from that JSON.

Never paste the key inside the playbook

A service account’s private_key is as sensitive as a password. Store it only as an encrypted credential and reference it by name; never put it as a literal activity parameter or as a file path on the robot.

Credential or OAuth connection?

If access is to a third-party account via OAuth (Google, Microsoft…), you will normally use an OAuth connection instead of a credential. The service-account JSON credential is the alternative without user consent (ideal for unattended runs).

Credentials live in an environment

A credential belongs to the environment where you create it and is only visible to agents in that environment. This is intentional and very helpful:

• In Tests you aim for a test system; in Production, in real.
• The same playbook works in both without changes, because it references the credential by name (erp), and each environment resolves its own value.

Playbook:  = credential("erp")
                  │
   ┌──────────────┴───────────────┐
Entorno "Pruebas"          Entorno "Producción"
 erp → erp-test.com         erp → erp.miempresa.com

Convention: same name in each environment

Use the same logical name for the credential in all environments (erp, not erp-prod and erp-test). Thus the playbook is identical everywhere and only the value changes depending on where it runs.

Globals and inheritance

A credential can be global (the Credentials menu): it is inherited by every environment automatically, and a local credential with the same name shadows it in its environment. That is the sharing mechanism: what is common lives in global; what is specific overrides per environment. Each environment’s credentials tab also shows the inherited globals and whether they are shadowed.

Copying across scopes

Every credential has a Copy to… action (to global or to another environment): the secret is re-encrypted server-side — it never travels through the browser — and if the name already exists in the target, the copy is rejected. There are deliberately no cross-environment “links”: a link from testing to production’s secret would break the isolation environments guarantee.

Update a credential

You can add, modify, or replace the values of an existing credential. The changes apply from the next run you use it; ongoing runs are not affected. You do not need to republish any packages.

Good security practices

• Nombres descriptivos y consistentes: erp-produccion, gmail-notificaciones.
• One credential per system and per environment: do not reuse the same one in production and testing.
• Periodically rotates secrets updating only the value in the portal.
• Principle of least privilege: that the account behind the credential has only the permissions that the bot needs.

Next steps

• Using credentials in automations — how to reference them from a playbook.
• Environments — how to separate production and testing.