Testing and debugging

Testing Zone runs a deployed Decision Table, Ruleset, Scorecard, Workflow, HTTP Client, or Coding HubItem with a controlled input. It supports exploratory runs, reusable payloads, assertions, workflow node mocks, and detailed traces.

What a test actually runs

Select an environment before running. The execution uses:

• the HubItem version deployed in that environment;
• deployed dependency versions selected by the Workflow;
• that environment's Global Variable values;
• that environment's connector configuration;
• your testing and debug permissions.

Saving a change in Designer does not replace the deployed version. When a result looks stale, compare the open version with the environment progression status first.

Run an exploratory test

1. Open the executable HubItem and select Testing Zone.
2. Choose an environment with a deployed version.
3. Build the request in the structured input editor or switch to JSON.
4. Import a JSON file if you have a sanitized example.
5. Enable Debug when you need a trace and have permission.
6. Select Run.
7. Inspect the response, error, and Debug view.

The structured editor follows the input Data Model and is useful for discovering required fields. JSON is useful for copying realistic nested payloads. Search helps locate fields in a large contract.

Example test matrix

For an eligibility decision, do not save only the happy path:

Test	Input focus	Expected outcome
Standard approval	Typical valid values	Approved
Exact minimum age	Boundary value	Policy-defined boundary result
Below minimum age	One value below boundary	Declined with reason
Missing income	Required/optional behavior	Validation or review
Zero requested amount	Unusual numeric input	Explicit expected result
Unsupported country	Unknown category	Fallback path
High-risk overlap	Matches several rules	Intended final values

Test names should state behavior, not sequence numbers.

Saved payloads

A payload stores reusable input without assertions. Use payloads for demonstrations, exploratory testing, and shared examples. Organize them in nested folders such as:

Loan Applications
  Valid
  Boundary Cases
  Invalid
  Integration Samples

Payload compatibility is based on the input model. Loading a payload replaces the current input, so inspect environment-specific IDs and remove sensitive data before saving.

Saved tests and assertions

A saved test combines:

• name and optional test folder;
• input payload;
• expected-result assertions;
• workflow node mocks when needed.

Choose an output field, comparison operator, and expected value from the assertion editor. Assert stable business outcomes:

status equals "Approved"
riskBand equals "Low"
approvedAmount equals 25000
reasons is empty

Avoid asserting timestamps or generated references unless their exact format is the behavior under test.

Run the case before saving. The Tests explorer then shows its deployment availability, run state, and pass/fail outcome. Folders can be named and colored to mirror domains, release packs, or regression suites.

Workflow node mocks

A node mock supplies an expected node output without executing the real dependency. It is valuable for external systems and hard-to-reproduce branches.

Example mock for a customer-profile HTTP node:

{
  "customerId": "C-1007",
  "status": "Active",
  "riskFlags": []
}

Create separate tests for:

• active customer response;
• suspended customer response;
• risk flags present;
• dependency error or empty response where supported.

Mocks prove the Workflow's reaction to a response; they do not prove the URL, credential, schema, or external service works. Maintain at least one real integration smoke test per environment.

Read a debug trace

For a Workflow, start at the first step and ask four questions for every node:

1. Why did this node run?
2. What input did it receive?
3. What output or mutation did it produce?
4. Which connection or branch ran next?

Debug data can include:

• ordered node timeline;
• node input/output;
• execution context and input changes;
• Decision Table and Ruleset condition evaluations;
• Scorecard contributions;
• nested workflow executions;
• errors and failed nodes.

For a Decision Table, inspect matching rows and writes. For a Ruleset, inspect rule priority and actions. For a Scorecard, inspect partial scores. For Coding, inspect modeled input/output and the reported error.

Correlation and history

Execution History provides organization-level records searchable by correlation ID, HubItem type, executor, and time. Use the same correlation ID to connect API activity, Workflow traces, and Integration Activity.

Debug data may contain sensitive payloads. Access requires a separate permission, and retention policies can remove records or diagnostic data after the configured period.

Troubleshooting sequence

When a test fails, check in this order:

1. Correct organization, solution, HubItem, and environment.
2. Expected version is deployed.
3. Input matches the deployed Data Model.
4. Required edge mappings are present.
5. Dependency versions are deployed.
6. Global Variables have values in this environment.
7. Connector test and workflow health succeed.
8. Debug trace identifies the first unexpected step.
9. Assertions match the intended output type and path.

Fix the first divergence rather than the final incorrect response; later symptoms often follow from one missing mapping near the start.