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>
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.
GUI installation (recommended)
-
In n8n, go to Settings → Community Nodes.
-
Click Install.
-
Enter the npm package name:
@probo/n8n-nodes-proboTo pin a specific version, append it (for example
@probo/n8n-nodes-probo@0.199.0). -
Accept the community node risk notice and click Install.
-
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
-
Add a Probo or Probo Trigger node to a workflow.
-
Open the Credential dropdown and select Create New Credential.
-
Fill in the fields:
Field Default Description Probo Server https://us.probo.comBase URL of your Probo instance. Use https://eu.probo.comfor the EU region, or your own URL when self-hosting.API Key — A Probo API key with access to the organizations you automate against. -
Click Test to verify connectivity. n8n calls the Probo GraphQL API and checks that the key is valid.
-
Click Save. The credential is shared across all Probo nodes in your instance.
Get an API key
- Sign in to the Probo console.
- Go to Settings → API Keys.
- Click Create API Key.
- 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
-
Create credentials as described above and save them as
Probo API. -
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)
-
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 }}
- Text:
- Map fields from the webhook payload, for example:
-
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:
- Add a Schedule Trigger node (for example, every weekday at 9:00).
- Add a Probo node:
- Resource: Task
- Operation: Get Many
- Organization ID: your organization GID
- Return All: enabled (or set a Limit)
- Add a downstream node (Slack, email, or spreadsheet) to process
$jsontask 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.
Links
License
MIT