Branching - Records Disappear into Thin Air?

Integrator.io
1

I'm sure there is a solution for this, but would love to hear what Celigo's best practice is for this scenario.

If a record doesn't qualify for a branch, it appears that the record just disappears into thin air and I have no idea that this record ever came in (since it didnt error out). Whats the best solution here other than making sure my branches account for all possible scenarios?

2

The current recommendation would be to always make a last branch that has no criteria (assuming you're using the first matching branch criteria) so that anything not meeting the criteria of your first branches ends up in this last one. Now, this would currently still look like it disappeared, but we have some enhancements coming to add more visibility. We also will be auto-adding an "else" branch so that you don't have to manually do this every time.

In the meantime, you could have a dummy import on that else branch that throws an error. That way, you force an error anytime the branch condition isn't met.

Adding @priyankakoundal and @sreevaniamara as they are working on the enhancements in this area.

3

Thanks Tyler for the quick response on this, and I am super happy to hear that there are enhancements coming here in the future.

Just my 2 cents, but what I would love to see for this is the payload error out in the branch itself and indicate that it didn't qualify for any existing branches. This then (similar to how errors are dealt with today on any import, lookup etc.) can give the end user the chance to review the payload and either:

  1. Resolve the error
  2. Change the payload so that it can then qualify for a branch and proceed down the rest of the flow

I think the most important part (from my perspective) is that the error can be caught at the actual branch step (without going down a branch) so that it can be re-tried.

1 Like
4

I've got several integrations that use branching to route different messages to different actions, and that are supposed to stop processing messages that don't fit any of of the filter-criteria on the branches.

Also cases where there isn't real branching, but where using a branch to stop processing a record is better then passing it on and having to test it on each step.

The image shows a flowchart diagram with blocks labeled "list items," "some lookup," "Create Item," and "Create Stock," connected by arrows, depicting a process flow with an "Item is active" decision point. (Captioned by AI)
The image shows a flowchart diagram with blocks labeled "list items," "some lookup," "Create Item," and "Create Stock," connected by arrows, depicting a process flow with an "Item is active" decision point. (Captioned by AI)2560×322 24.9 KB

Throwing an error on the branching would break this, so not something I'd be a fan of. Adding a dummy 'else' branch could work, because then you could see the skipped records in the Run Console. Maybe the the branch step itself could be shown as a 'real' step in the run console, showing what records it routed, and what it didn't? Extra nice if the run console can be formatted as a tree.

5

From a UI point of view, that flow would definitely look better if you had a branch that led to nowhere because it would more clearly show records are dropping off.

For throwing errors, our idea was to give the option to throw an error if no criteria are met. Sort of like lookup mappings where you can choose to fail the record if no lookup value is found. The default behavior would probably be to leave it as it is now.

For the run history log, we are working to completely revamp this. We have discussed more of a tree view so it shows more like the flow itself. It can get tricky when branches then merge back and you have 10 branches, but we are working through this. Ideally, we would also show an entry in the run history for the dead-end branch so you could see how many records went there and got dropped.

1 Like