Files
probo/packages/n8n-node/README.md
Sacha Al Himdani 944bcb7380 Add updated-from entity snapshot to updated webhooks
Update webhook events now carry a top-level "updatedFrom" field
alongside "data", containing a full snapshot of the entity as it was
before the update. This lets subscribers diff old vs new state (for
example the prior membership role on user:updated) without tracking
prior state themselves. It is a complete snapshot with the same shape as
"data", not a partial diff, so consumers select whatever fields they
need. The field is omitted for non-update events.

The webhook_data table gains a nullable updated_from JSONB column, and
webhook.InsertUpdateData enqueues both snapshots; InsertData delegates to
it with a nil updatedFrom so non-update callers are unaffected. Each
*:updated emission site snapshots the entity right after load, before
mutation: obligation, third-party, user (org and SCIM flows), document,
document-version, and document-version-approval-quorum. The document
emit helpers gained an optional updatedFrom argument threaded through to
the payload.

For document-version-approval-quorum:updated the snapshot requires an
extra query, so it is now gated behind the same subscription-existence
check the emitter uses: when no subscriber is configured the load is
skipped entirely rather than running (and potentially failing the
approval) for an event nobody receives.

Add integration tests (against a real Postgres, skipped when none is
reachable) covering the updated_from round-trip, the SQL NULL behavior
when no snapshot is provided, and the no-op when no subscription matches,
plus a unit test asserting updatedFrom is omitted from the payload when
absent.

Document the new field in the probod and n8n changelogs and the n8n
README.

Signed-off-by: Sacha Al Himdani <sacha@probo.com>
2026-07-15 13:59:41 +02:00

6.1 KiB

@probo/n8n-nodes-probo

n8n community node package for the Probo compliance platform. Automate compliance workflows — manage controls, documents, risks, vendors, cookie banners, and more — over the Probo GraphQL API.

This package provides two nodes:

Node Type Description
Probo Action Read and write Probo resources (tasks, documents, controls, organizations, and 30+ other resources)
Probo Trigger Trigger Start a workflow when Probo webhook events occur (document published, user created, obligation updated, and more)

Requirements

  • A self-hosted n8n instance with community nodes enabled
  • A Probo account with an API key
  • n8n 1.0+ (uses the community node package format)

Installation

Install the package from npm on your self-hosted n8n instance. Only users with the Owner or Admin role can install community nodes.

  1. In n8n, go to Settings → Community Nodes.

  2. Click Install.

  3. Enter the npm package name:

    @probo/n8n-nodes-probo
    

    To pin a specific version, append it (for example @probo/n8n-nodes-probo@0.199.0).

  4. Accept the community node risk notice and click Install.

  5. Restart n8n if the new nodes do not appear in the node palette immediately.

See the n8n GUI installation guide for details.

Manual installation

If you run n8n in Docker or queue mode, you can install the package manually:

mkdir -p ~/.n8n/nodes
cd ~/.n8n/nodes
npm install @probo/n8n-nodes-probo

Restart n8n after installation. See the manual installation guide for upgrade and downgrade steps.

Credentials

All Probo nodes use the Probo API credential type. The node sends your API key as a Bearer token on every request.

Configure credentials in n8n

  1. Add a Probo or Probo Trigger node to a workflow.

  2. Open the Credential dropdown and select Create New Credential.

  3. Fill in the fields:

    Field Default Description
    Probo Server https://us.probo.com Base URL of your Probo instance. Use https://eu.probo.com for the EU region, or your own URL when self-hosting.
    API Key A Probo API key with access to the organizations you automate against.
  4. Click Test to verify connectivity. n8n calls the Probo GraphQL API and checks that the key is valid.

  5. Click Save. The credential is shared across all Probo nodes in your instance.

Get an API key

  1. Sign in to the Probo console.
  2. Go to Settings → API Keys.
  3. Click Create API Key.
  4. Copy the key immediately — it is shown only once.

For self-hosted Probo, set Probo Server to your instance URL (for example https://probo.example.com). The node talks to /api/console/v1/graphql on that host.

More detail: Probo n8n authentication docs.

Workflow example: notify Slack when a document is published

This workflow listens for Probo document events and posts a message to Slack.

Probo Trigger  →  Slack
(document      (post message
 published)     with document name)

Steps

  1. Create credentials as described above and save them as Probo API.

  2. Add a Probo Trigger node

    • Credential: Probo API
    • Organization ID: your Probo organization GID (for example gid://probo/Organization/…)
    • Events: Document Version Published
    • Verify Signature: enabled (recommended)
  3. Add a Slack node (or any notification node) connected to the trigger output.

    • Map fields from the webhook payload, for example:
      • Text: A document was published: {{ $json.data.documentVersion.document.name }}
  4. Activate the workflow. n8n registers a webhook subscription in Probo. When a document version is published, Probo delivers the event and the Slack message is sent.

Update events carry the previous state

For *:updated events, the payload includes an updatedFrom object next to data, holding a full snapshot of the entity as it was before the update. This lets a workflow react to what actually changed — for example, only notify when a user's role changes:

  • Condition: {{ $json.data.membership.role !== $json.updatedFrom.membership.role }}
  • Text: Role changed from {{ $json.updatedFrom.membership.role }} to {{ $json.data.membership.role }}

updatedFrom is present only on update events; it is absent for created, deleted, and other lifecycle events.

Alternative: list open tasks on a schedule

Use the Probo action node without a trigger:

  1. Add a Schedule Trigger node (for example, every weekday at 9:00).
  2. Add a Probo node:
    • Resource: Task
    • Operation: Get Many
    • Organization ID: your organization GID
    • Return All: enabled (or set a Limit)
  3. Add a downstream node (Slack, email, or spreadsheet) to process $json task records.

This pattern works well for daily compliance standups or overdue-task digests.

Resources

The Probo node exposes operations across the platform, including:

Access Review, Asset, Audit, Audit Log, Control, Cookie Banner, Cookie Category, Cookie Consent Record, Data, Document, DPIA, Evidence, Finding, Framework, Measure, Obligation, Organization, Processing Activity, Risk, Task, Third Party, Trust Center, User, Vendor, and more.

Use the Execute resource to run custom GraphQL queries or mutations when a dedicated operation is not available.

License

MIT