FlowRag — knowledge/delete

When to Use

Content retirement: When a policy is superseded, a product is discontinued, or a support article is unpublished, delete it from the knowledge base to prevent AI nodes from retrieving outdated information.
Correction workflow: If incorrect content was inserted, delete it before re-inserting a corrected version. This ensures the bad embedding is fully purged from the vector store.
GDPR or data retention compliance: When a user's data must be erased under a right-to-erasure request, delete the corresponding knowledge items that contain that data.
Collection cleanup: Remove test or staging documents that were inserted during development before the collection goes live in production.

Irreversible operation: Deletion permanently removes the document and all its embedding chunks from the vector store. There is no undo. If the content may be needed again, consider using knowledge/update to replace content with an archival notice rather than deleting outright. Always persist the knowledgeId from the original insert in your source system before deleting.

Configuration

Connection

Field	Required	Description
`providerName`	Required	Vector store provider. One of: `pinecone`, `weaviate`, `chroma`, `qdrant`, `pgvector`. Must match the provider used at insert time.
`collectionName`	Required	The collection name from which to delete the document. Must match the collection used at insert time.
`credentialId`	Optional	Credential ID for the vector store, stored in the BizFirst Credentials Manager.

Operation

Field	Required	Description
`knowledgeId`	Required	The GUID of the document to delete. Must be a valid UUID string returned by the original `knowledge/insert` or `knowledge/update` operation. Supports `{{ expressions }}`.

Sample Configuration JSON

{
  "nodeType": "flow-rag",
  "resource": "knowledge",
  "operation": "delete",
  "providerName": "qdrant",
  "collectionName": "hr-policies",
  "credentialId": "88",
  "knowledgeId": "{{ $input.knowledgeId }}"
}

Validation Errors

Error	Cause
`collectionName is required`	`collectionName` is empty or missing.
`providerName is required`	`providerName` is empty or missing.
`knowledgeId is required`	`knowledgeId` is empty after expression evaluation.
`knowledgeId is not a valid GUID: '...'`	`knowledgeId` is not a valid UUID string. Ensure it was taken directly from the original insert output without modification.

Output

Success Port

Field	Type	Description
`knowledgeId`	string (GUID)	The GUID of the document that was deleted, for confirmation.
`collection`	string	The collection from which the document was deleted.
`status`	string	`"success"`
`errorMessage`	string	Empty on success.

Error Port

Fires when the deletion fails. Common causes: document not found, vector store unreachable, invalid credentials, or malformed GUID.

Field	Type	Description
`knowledgeId`	string (GUID)	The GUID that was supplied to the delete operation.
`collection`	string	The collection that was targeted.
`status`	string	`"error"`
`errorMessage`	string	Human-readable error description from the vector store provider.

Sample Output JSON

Success

{
  "knowledgeId": "a3f2c1d4-8e5b-4a90-b231-7c6e9f12d847",
  "collection": "hr-policies",
  "status": "success",
  "errorMessage": ""
}

Error

{
  "knowledgeId": "a3f2c1d4-8e5b-4a90-b231-7c6e9f12d847",
  "collection": "hr-policies",
  "status": "error",
  "errorMessage": "Document not found in collection 'hr-policies'. It may have already been deleted."
}

Expression Reference

Expression	Returns
`{{ $output.deleteNode.knowledgeId }}`	GUID of the deleted document.
`{{ $output.deleteNode.collection }}`	Collection name from which the document was deleted.
`{{ $output.deleteNode.status }}`	`"success"` or `"error"`.
`{{ $output.deleteNode.errorMessage }}`	Error description on failure, empty on success.

Node Policies & GuardRails

Policy	Detail
GUID format validation	The `knowledgeId` is validated as a well-formed UUID string before any request is sent to the vector store. Invalid GUIDs fail immediately at the validation stage with a descriptive error, preventing spurious delete attempts.
Collection scoping	The delete is scoped to the specified `collectionName`. A document cannot be accidentally deleted from a different collection even if the same GUID exists there.
Credential isolation	Vector store credentials are resolved from the BizFirst Credentials Manager at runtime. Raw connection strings are never stored in node configuration.
Audit logging	Every delete operation is logged to the BizFirst execution audit trail with timestamp, collection, knowledgeId, and executor identity for compliance and traceability.
No cascade	Deleting a knowledge item does not affect any other items in the collection. Only the specific document identified by the `knowledgeId` is removed.
Error port handling	Always wire the error port to a handler in production. A "document not found" response from the vector store routes to the error port — this may be acceptable in idempotent pipelines and should be handled explicitly.

Examples

Example 1 — Delete a Retired Policy on Publication Event

A WebhookTrigger fires when a policy is archived in the CMS. The workflow retrieves the stored knowledgeId from the database and calls delete.

{
  "nodeType": "flow-rag",
  "resource": "knowledge",
  "operation": "delete",
  "providerName": "pgvector",
  "collectionName": "company-policies",
  "credentialId": "55",
  "knowledgeId": "{{ $db.policyRecord.ragKnowledgeId }}"
}

After successful deletion, a downstream DataMapping node clears the ragKnowledgeId field in the database record to indicate the content is no longer in the knowledge base.

Example 2 — Idempotent Delete with Error Port Handling

In a cleanup workflow that may run multiple times, the error port handles "document not found" gracefully by logging and continuing rather than failing the workflow.

{
  "nodeType": "flow-rag",
  "resource": "knowledge",
  "operation": "delete",
  "providerName": "qdrant",
  "collectionName": "support-articles",
  "credentialId": "88",
  "knowledgeId": "{{ $input.articleKnowledgeId }}"
}

Connect the success port to a confirmation step. Connect the error port to an IfCondition node that checks {{ $output.deleteNode.errorMessage }} — if it contains "not found", treat as success; otherwise escalate.

Example 3 — GDPR Erasure Workflow

A right-to-erasure request arrives. A Loop node iterates over all knowledgeId values associated with the subject's data and calls delete for each.

{
  "nodeType": "flow-rag",
  "resource": "knowledge",
  "operation": "delete",
  "providerName": "pinecone",
  "collectionName": "customer-interactions",
  "credentialId": "101",
  "knowledgeId": "{{ $item.knowledgeId }}"
}

After all deletions complete, an audit record is written confirming the erasure date, operator identity, and the list of deleted knowledgeId values — producing a compliant data erasure audit trail.