Event-driven automation with WOODY.IO Notifications

Problem Overview

After an import is validated and persisted, most teams need follow-up steps such as refreshing Databricks tables, triggering Azure workflows, or notifying stakeholders. If those steps are run manually or implemented differently per team, the result is inconsistent execution, missed runs, and slow troubleshooting. A common issue is missing context: people and systems do not know which import triggered the action, how many rows were processed, or whether errors occurred, etc.

Solution

WOODY.IO Notifications provide a standard mechanism to turn Import lifecycle events into reliable downstream automation, with enough context to make automation safe and traceable.

What WOODY.IO Notifications provide

1. Trigger on Import state changes such as “Ready to persist”, “Archived”, or “Error Persisting”
2. Support filters so notifications run only for the intended scope such as Import Template, Metamodel, Persist Type, and counts
3. Support tokens so outgoing messages and calls include execution context such as {import}, {row_count}, {warning_count}, {error_count}
4. Provide delivery types relevant to automation (e.g.,):
   1. Databricks notifications for SQL, notebooks, or jobs
   2. HTTP Request notifications for Azure Functions, Logic Apps, and internal Webhooks, with Key Vault references supported for URL and headers where available.

Recommended patterns

Trigger a Databricks process once the Persist succeeded

Use a Databricks notification to run transformations or publishing only when WOODY.IO has completed the step you consider “ready”. This prevents race conditions where Databricks starts before data is ready, and it standardizes the publish step across templates and teams.

Typical flow:

1. Import is validated and optionally approved
2. Persist completes
3. Databricks notification runs SQL, a Notebook, or a Job

Azure workflow when the Import is finished

Use an HTTP Request notification to trigger an Azure Function or Logic App after the import is finished. This is useful for things like notifying other systems, creating a ticket, updating a catalog, or starting another pipeline.

Typical flow:

1. Import finishes
2. HTTP Request notification calls a Webhook
3. Azure workflows can route execution based on fields in the request payload, such as the error count or the persist type

Quality signals then targeted alerts

Use filters and tokens so notifications are sent only when they matter. For example, send an alert only if errors occurred, and include the error and row counts to speed up troubleshooting.

Configuration

Go to Management > Notifications > Add Notification.

Configure these elements.

Trigger states

Choose the Import lifecycle state/states that should trigger the automation, for example:

• Ready to persist
• Archived
• Error Persisting

Select states based on intent:

• Use Archived when you want a “done and stable” signal
• Use Error Persisting for incident and alert flows
• Use Ready to persist only when you intentionally want automation before persist

Filters

Add filters so the notification applies only where it should. Common filters include:

• Metamodel
• Import Template
• Persist Type
• Counts such as Error Count, when available in filters

Filters prevent accidental triggers across unrelated imports.

Tokens

Use tokens in messages, HTTP bodies, and parameters to include context:

• {import}
• {row_count}
• {warning_count}
• {error_count}

See the article Notifications - How to Configure and When for a more hands on guide.

If you have any further questions, please feel free to Contact Us.