DataHub Error Log
Overview
The DataHub Error Log is the central place within 3PL Dynamics where all errors from your DataHub integrations are collected, classified, and managed. Whenever an integration flow fails in the Azure cloud, the error is pushed to an Azure Queue and subsequently pulled into Business Central, where it becomes visible in the DataHub Error List.
From a single overview you can:
- Monitor all incoming integration errors across every flow and party
- Track the status and severity of each error
- Navigate directly to the Flow Run where the error occurred
- Inspect the error message and stack trace for root cause analysis
- Configure Error Rules to automatically classify errors by severity
How It Works
Azure Cloud (DataHub)
│
│ Error occurs in a Flow Run
│
▼
Azure Error Queue
│
│ Pulled on Refresh (or scheduled)
│
▼
DataHub Error Log (Business Central)
│
├─ Error Rule Evaluator runs automatically
│ └─ Assigns Severity based on configured rules
│
└─ Error List page shows grouped tree view
When you click Refresh on the Error List, Business Central fetches all pending messages from the Azure Queue and stores them in the Error Log. After importing, the Error Rule Evaluator runs automatically to assign a severity level to each new entry based on your configured Error Rules.
The Error List
Navigate to the Error List via: Alt+Q → DataHub Error List
The list displays errors in a hierarchical tree view. Parent entries represent the primary error event and are shown in bold. Child entries represent duplicate or related errors that were grouped under the same parent based on the exception hash (a SHA-256 fingerprint of the error message).
By default the tree is fully collapsed — expand a parent row to see all related child errors.
Columns
| Column | Description |
|---|---|
| Date / Hour | The date and hour (YYYYMMDDHH) when the error occurred |
| Status | The current handling status of the error |
| Severity | The classified severity level (Low, Medium, High, Critical) |
| Time Stamp Error | The exact date and time the error was logged |
| Core Version | The DataHub core version at the time of the error |
| Flow Description | The name of the integration flow that failed |
| Exception Message | A preview of the error message |
| Number of Errors | The total count of entries in this group (parent + children) |
| Run Id | The unique identifier of the specific flow run that failed |
| Flow Id | The unique identifier of the integration flow |
| Modified Date/Time | When the error entry was last modified |
| Modified User ID | The user who last modified the entry |
Default View
The page opens with a filter on Status = New so you immediately see only unhandled errors. You can remove this filter to see all error statuses.
Error Status
Each error entry has a Status that reflects its handling lifecycle. Use the Set Status action to progress an error through the workflow.
| Status | Description |
|---|---|
| New | The error has just arrived and has not yet been looked at |
| To Investigate | The error has been flagged for further analysis |
| Investigating | Someone is actively looking into the error |
| Restarted | The related flow run has been restarted from the DataHub portal |
| Resolved | The underlying issue has been fixed |
| No Action Required | The error is known and does not require any action |
| Cannot Reproduce | The error could not be reproduced and is considered closed |
⚠️ Important: Changing the status of a parent entry also updates all its child entries to the same status.
Error Severity
The Severity indicates how critical an error is. It is assigned automatically by the Error Rule Evaluator when new errors are imported. If no rule matches, the default severity is Medium.
| Severity | Description |
|---|---|
| Low | Minor issue; no immediate action needed |
| Medium | Standard integration error; should be investigated in due course |
| High | Significant error affecting business processes; investigate promptly |
| Critical | Blocking error with direct business impact; requires immediate attention |
The severity is color-coded in the list for quick visual identification: Critical errors are shown in red, High in orange/amber, Medium in yellow, and Low in green.
📚 Note: The severity of a parent entry reflects the highest severity found among itself and all its child entries.
Actions
Set Status
Changes the status of one or more selected error entries. A menu lets you choose from all available statuses. Child entries of a selected parent are updated automatically.
Open Flow Runs
Opens the DataHub Flow Run list filtered to the flow and run associated with the selected error. Use this to inspect the individual action steps and find exactly where the error occurred.
📚 Related: For a full explanation of the Flow Run view, see Data Hub Transactions.
Open Error Message
Opens the full exception message text in a viewer. This contains the detailed description of what went wrong.
Open Stack Trace
Opens the technical stack trace for the error. This is useful when escalating to support as it shows the exact execution path through the DataHub core.
Error Rules
Opens the Error Rules configuration list. See Error Rules below.
Refresh
Pulls new error messages from the Azure Queue and runs the Error Rule Evaluator. Use this to manually fetch the latest errors without waiting for the next scheduled run.
Delete
Deletes the selected error entries. When deleting a parent entry, all its child entries are also deleted. A confirmation dialog shows the number of records that will be removed.
Error Rules
Error Rules allow you to automatically classify incoming errors by severity based on their content or occurrence count. Instead of every error getting a default Medium severity, you can configure rules to immediately flag certain patterns as Critical or suppress known harmless errors as Low.
Rule Types
There are two levels of rules: General rules and Flow-specific rules.
General Rules
- Apply to all errors, regardless of which flow they come from
- Only one General rule entry is allowed
- Contains multiple individual conditions (see Rule Conditions below)
Flow-specific Rules
- Apply only to errors from a specific flow (identified by Flow Id)
- Multiple flow-specific entries can exist — one per flow
- Can optionally overwrite the General rules (see Overwrite General)
Overwrite General
When a Flow-specific rule has Overwrite General enabled, the General rules are not applied to errors from that flow. Only the conditions in the Flow-specific rule are evaluated.
When Overwrite General is disabled (default), both the General rules and the Flow-specific rules are evaluated together for errors from that flow.
Rule Conditions
Each rule entry (General or Flow-specific) contains one or more conditions. These are the actual matching criteria that determine whether a rule applies to a given error.
Condition Fields
| Field | Description |
|---|---|
| Rule Type | The matching method: Contains, Regex, or Count |
| Value | The value or pattern to match against |
| Priority | Evaluation priority (lower number = higher priority) |
| Severity | The severity level to assign when this condition matches |
Rule Types
Contains
Performs a case-insensitive text search in the exception message. The rule matches if the error message contains the specified value anywhere in its text.
Example:
Rule Type: Contains
Value: timeout
Severity: Low
This rule matches any error whose message contains the word "timeout" (regardless of casing) and classifies it as Low severity.
Regex
Evaluates a regular expression pattern against the exception message. Useful for more precise matching, such as specific error codes or structured patterns.
Example:
Rule Type: Regex
Value: ^HTTP 40[134]
Severity: High
This rule matches errors where the message starts with HTTP 401, 403, or 404, and classifies them as High severity.
⚠️ Note: The regex pattern is validated when you save the condition. An invalid pattern will produce a validation error.
Count
Matches based on the total number of errors in a group (parent + children). Use this to escalate severity when the same error recurs many times.
Example:
Rule Type: Count
Value: 10
Severity: Critical
This rule matches when a single error occurs 10 or more times, classifying the group as Critical.
Evaluation Logic
When new errors are imported, the Error Rule Evaluator applies the following logic:
Collect applicable rules for the error's Flow Id:
- Always include General rules, unless a Flow-specific rule has Overwrite General enabled
- Include Flow-specific rules for the matching Flow Id if they exist
Evaluate each condition against the error:
- Contains: check if exception message contains the value
- Regex: check if exception message matches the pattern
- Count: check if the total error count meets or exceeds the threshold
Determine the final severity from all matched conditions:
- The condition with the lowest Priority number wins
- If multiple conditions share the same priority, the highest Severity wins
- If no conditions match, the error receives the default severity: Medium
Update both the child and parent error log entry with the determined severity
Configuration Guide
Setting Up a General Rule
Use general rules to catch common error patterns that apply across all your integrations.
- Navigate to
Alt+Q→ DataHub Error Rule - Click New
- Set Entry Type to
General - Enter a Description (e.g.
General Error Classification) - In the Conditions subpage, add one or more conditions:
- Choose a Rule Type
- Enter the Value to match
- Set the Priority (start at 1, 2, 3 for multiple conditions)
- Select the Severity to assign when matched
- Save the record
⚠️ Important: Only one General rule entry is allowed. All general conditions must be added as lines within that single entry.
Setting Up a Flow-specific Rule
Use flow-specific rules to override or extend the general classification for a specific integration.
- Navigate to
Alt+Q→ DataHub Error Rule - Click New
- Set Entry Type to
Flow - Use the Flow Id assist-edit button (or type directly) to select the flow
- Enter a Description
- Optionally enable Overwrite General if this flow's rules should replace the general ones
- Add Conditions in the subpage
- Save the record
Example Setup
The following example shows a typical classification setup:
General Rule (applies to all flows):
| Rule Type | Value | Priority | Severity |
|---|---|---|---|
| Contains | timeout | 10 | Low |
| Contains | connection refused | 10 | High |
| Count | 5 | 20 | High |
| Count | 20 | 20 | Critical |
Flow-specific Rule for an order integration flow:
| Rule Type | Value | Priority | Severity |
|---|---|---|---|
| Contains | customerId not found | 1 | High |
| Regex | ^HTTP 5\d\d | 1 | Critical |
| Count | 3 | 5 | Critical |
With Overwrite General disabled, both rule sets are evaluated for that flow. The condition with the lowest priority number (1 in the flow rule) will take precedence when it matches.
Common Scenarios
Scenario 1: All errors arrive with Medium severity
No Error Rules are configured. Configure a General rule with Contains and Count conditions to start classifying errors automatically.
Scenario 2: Known harmless errors show as High severity
Add a Contains or Regex condition for that specific error message with a lower priority number and set Severity to Low. Because it has lower priority, it will take precedence over general Count rules.
Scenario 3: A specific flow needs different thresholds
Create a Flow-specific rule for that flow. Enable Overwrite General if the general rules don't apply at all, or leave it disabled if you want both to be evaluated.
Scenario 4: Recurring errors should escalate automatically
Add a Count condition with the desired occurrence threshold. Set a higher Severity level and a priority number higher than specific message conditions (so message-specific rules can still override when applicable).