Workspace Weekly: Top 5 ways to use Custom and Secure values in Connector command lines
November 12, 2025
This week’s Workspace Weekly is a practical one. If your connector accepts command line options, you can pass custom values and secure custom values from Accounts straight into the connector’s invocation. That keeps configuration in Accounts, keeps secrets masked, and lets you change behavior at runtime without touching the connector configuration or code.
For step-by-step setup, see the docs: Custom Fields and Secured Custom Fields.
Setup and info:
- Tokens you can use in command lines: {custom1} … {custom5} and {securecustom1} … {securecustom5}.
- Custom fields accept any string up to 1,024 characters.
- Secure custom fields accept up to 255 characters, are write-only, and are encrypted at rest.
Figure 1: configuration page in Login Enterprise for Secure Custom Fields (Custom Fields expander above it)
1) One account to one target host
Use when: you want the same test account to always hit the same target.
Why: cleaner A/B comparisons and less triage clutter.
How: set Custom1 = target-01.yourdomain.com and call {custom1} in your connector’s command line.
Example:
Connector.exe “{host}” “{username}” “{password}” “{domain}” “{resource}” “{custom1}”
2) StoreFront or portal path selection
Use when: the launch path varies by user, folder, or collection.
Why: keep the flow data driven instead of hardcoded.
How: set Custom2 = /Dept/Apps/Finance and have the connector navigate using {custom2}.
Tip: pair with {sessionId} in Process Tracking to keep multi-session runs clean.
3) Environment toggles without rebuilds
Use when: the same connector must run in dev, test, and prod.
Why: ship once, steer per account.
How: set Custom3 = dev or test or prod, or use a flag like useNewFlow.
Example:
Connector.exe “{resource}” “{custom3}”
4) Sensitive connection values at runtime (secure)
Use when: the run needs an API token, header value, client secret, or a TOTP seed.
Why: keep secrets inside Login Enterprise. They are masked in the UI, encrypted at rest, and never returned by UI or API after saving.
How: set Secure1 = tenant-api-key or Secure2 = totp-seed and reference {securecustom1} or {securecustom2} in the invocation.
Example:
Connector.exe “{resource}” “{securecustom1}”
Note: secure fields are write-only. Rotate them the same way you rotate passwords.
5) Swap in alternates for standard fields
Use when: the identity you must log in with differs from the Account’s standard fields.
Why: keep Accounts stable while your connector logs in with alternates.
How: map {custom1} … {custom5} into username, password (securecustomX), domain, resource, and email.
Example:
Connector.exe –username “{custom1}” –password “{custom2}” –domain “{custom3}” –resource “{custom4}” –email “{custom5}”
Quick tips
- Name your convention: decide what each field means. For example, Custom1 = targetHost, Secure1 = API token.
- Do not log secrets: avoid echoing {securecustomX} in scripts or launcher logs.
- Test before you secure: validate with placeholders, then switch to secure fields.
- Pair with Process Tracking: if your run spawns another process, track the real client and include {sessionId} in a window title or command line token for uniqueness.
- Add breadcrumbs: pass {sessionId} to your connector and post Custom Events to so runs include precise, session-scoped notes.
Check out how to use this feature in a demo:
Ready to try 6.3? Upgrade your appliance, then follow this documentation to add and use custom values and secure custom values .
Don’t forget to join #workspace-weekly on Slack to share your own tips and stories. As always, your feedback helps make Login Enterprise better for you.
Workspace Weekly
