Connections

The Connections view of the Portfolio window links a workspace to the systems it already runs: cost codes, commitments and actuals from the ERP, people and timesheets from HCM, progress to the field tools, dashboards in BI. It also holds the workspace's API keys and outbound webhooks. Connections belong to the cloud workspace, so they need a signed-in account, and only a workspace owner changes them.

What a connection is

A connection is one connector from the catalogue plus your own addresses, credentials, mapping and schedule. The credentials are entered once, encrypted on the server and never shown again. A connection has a status (new, tested, healthy, failing), a last test, a last run and a run history.

The catalogue

The five pull capabilities are cost codes, commitments, actuals, timesheets and resources; the two push capabilities are forecasts and progress. Not every system offers every capability, and the catalogue says which.

Setting one up

1. Open the Portfolio window and the Connections view, then Add a connection and pick the system.
2. Give it a name and fill in the addresses the connector asks for: a tenant, a base URL, an environment. The placeholders show the shape.
3. Enter the credentials. They are stored encrypted and the form never shows them again; editing later leaves a blank field unchanged.
4. Under Mapping, name what to exchange for each capability: a path for the generic REST connector, a file pattern for SFTP, a report, orchestration, service or entity name for the named systems.
5. Pick a schedule (manual, hourly, daily, weekly) and create it. Then Test.

Tests, runs and schedules

Test makes one real request to the system with the stored credentials and reports what came back: reached and accepted, reached but the credentials were refused, or not reachable. Run now records a sync run: the connectivity check, then, for the generic REST connector, every mapped path fetched and its records counted and the fields seen. Scheduled connections run on their own and the next run time is shown on the card. Every run is kept with its outcome, trigger and detail; a failing run names the capability and the error rather than hiding it.

Inbound webhooks

An inbound webhook connection gives the other system a URL of its own under /api/hooks/ and a signing secret, shown once. The other system posts JSON (a list of records, or an object with a records array and a capability) with the header X-DeltaSys-Signature set to the HMAC-SHA256 of the raw body under that secret; an unsigned or badly signed post is refused. Each accepted post is a run with the record count.

API keys

A key lets your own code call DeltaSys as a member of the workspace: projects, enterprise setup, Time Control and connections. Send it as Authorization: Bearer dsk_…. Keys are named, shown once, listed with their last use, and revoked in one click; a revoked key is refused at once. See Data exchange and API for the resources.

Outbound webhooks

DeltaSys posts JSON to an https URL you give it when a sync completes or fails or a project is saved, with the header X-DeltaSys-Signature (HMAC-SHA256 of the body under the webhook's secret, shown once). Pick the events or leave them all on, and send a test delivery from the list; the last delivery and its status are shown.

Credentials and security

Credentials are sealed with AES-256-GCM under a key that lives only on the server, in a file readable by the API alone, and are decrypted only for the moment of a test or a run. The API never returns them; the list shows only which fields are set. Removing a connection deletes its credentials and run history. Every create, change, test and run is in the workspace event log. See Security and privacy.

What is verified where