Define in Management, run in Workflow

Setyenv lets you describe an integration once in WP-PFManagement — a REST call, an inbound scripted route, a table operation, an OAuth connection — and then use it as a native node inside a WP-PFWorkflow automation. You configure it in one place; the engine runs it in another. The definition and the execution are deliberately separated.

The Workflow node library showing per-entity table nodes and triggers that exist because the entity was modelled in Management

Who owns what

WP-PFManagement owns the definition. The connection's endpoints, the request/response shape, the scripted route's method and path, the OAuth client id/secret and token — all of it lives in Management, next to the entities and permissions it relates to. You edit it in Management's sidebar, with validation, versioning and the usual record history.
WP-PFWorkflow owns the execution. The workflow engine — queue, retry, replay, timeline, idempotency — plus the security guard rails (see The inherited moat below), the SSRF protection on every outbound call, the credential encryption and the typed node contract, all stay in Workflow. Workflow reads the definition from Management at run time and executes it.

Why separate them

One source of truth. The same REST connection or OAuth login is reused by every workflow that needs it. Change the endpoint once in Management and every automation follows.
The right guard rails apply automatically. Because Workflow runs the definition, a call defined in Management still inherits Workflow's certified engine and Management's own record-level permissions — you cannot accidentally build an integration that skips them.
It degrades safely. Workflow resolves each definition Management-first, falling back to a local copy when Management is not installed, so a workflow keeps working while you adopt the platform piece by piece.

What you actually see

In the Workflow node library, integrations defined in Management appear as ready-to-wire nodes: a Connections group for REST messages and OAuth-backed HTTP calls, and a Management group with one set of table nodes (Get / Create / Update / …) per entity you have modelled. You drag them onto the canvas like any built-in node.