A Connection separates endpoint metadata, connector, authentication method and protected credential custody from Mapping logic. Available fields and methods depend on the chosen connector. A technology appearing in the catalog does not prove that a worker has the driver, network path or permissions needed to use it.
Before you begin
Prepare an authorized laboratory resource, preferably read-only. Identify the worker performing the test and its runtime identity. Do not put passwords, keys or sensitive Vault references into descriptions or screenshots.
Procedure
- Open Connections and create a record whose name describes its purpose. Select the connector and inspect required fields.
- Enter authorized metadata: host or endpoint, port, database, schema or resource as applicable. Confirm values with the environment owner.
- Choose an offered authentication method and custody mode. Passwordless uses a runtime identity; external custody requires a resolvable protected reference. Do not force hidden methods into the form.
- Complete the protected input flow, review tenant and save. Check persisted metadata before testing.
- Use Test for the saved Connection and read the safe result. Then run a small extraction through a Mapping/Session on a compatible worker.
- Review consumers before rotating, revoking or deleting the Connection. Distinguish metadata editing from replacing credentials.
Verify the result
The Connection exposes only permitted metadata; its test reports the expected state and a small read produces known output. Compare identifiers with the editor. A successful connection test does not certify every write, retry or recovery mode.
Errors and recovery
For authentication errors, inspect method, custody, permissions and expiry. For network errors, check DNS, TLS and worker egress. A missing driver requires checking installed capabilities. Keep messages safe and never copy secrets into a description field for debugging.
Synthetic example
CustomerLabReadOnly addresses synthetic database training and table customers through a read-only identity. Select it in the appropriate source component and verify ten known records.
Verification scope
Use synthetic data and the role authorized for the task. Compare a visual confirmation with the saved record or relevant attempt. Retain only safe identifiers and messages for support; do not share secrets, personal information or tenant data. If an operation outcome is uncertain, check its state before repeating it.
Environment context
Before using this module, confirm Tenant, Domain and Environment in the user menu. The initial environment is Development. Module, Domain and environment capabilities apply together; Production is read only without explicit authorization. Switching the selector does not move artifacts or publish or execute their data. See environments and recovery and environment promotion.
Prepare destination Connections
Before promoting to Production, prepare target-owned Connections with valid custody and permissions. An authorized administrator can register them or change metadata with etl.connections.manage and etl.environments.production.edit. This specific authorization does not unlock Production Mapping, Session or Workflow editors. Shared or ambiguous legacy Connections stay read only.
Promotion and Fork to Development previews offer only compatible existing destination Connections. Select each replacement explicitly; passwords are not copied and secret references are not fabricated. Connection Domain and Environment remain tied to their ownership context.
Worker availability and view loading
A reference to a removed worker or a worker with an invalid identity does not prevent you from opening Overview, Monitor or Connections. That reference is not available for execution; valid workers remain visible within your permissions. A real storage or policy failure is reported as an error and is not converted into a zero counter.