A system to chain rules


Here is a setup that works for me to chain rules together.
(Note: the actual terminology I use is different, as you can see in the examples at the bottom)


There is a challenge to take into account related to a loop error message when a rule is re-used in the same chain. This is a known limtation. In my case, the chain items used the same rule to create a rule run, which resulted in this loop error. See also

To workaround this, I precreated 4 rules for chain items, each triggering the next chain item. This is a one-time setup that will work for all the rule chains that you create. If you need longer chains, just add more chain items.

I use the following databases:


FYI, there are no plans to change the current behaviour for loop detection.


False loop detection has been a recurring issue for me.

Please post what you’re attempting and what the outcome is

Hello @Chr1sG / Fibery team,

We are also experiencing a loop and we just can’t figure out how to avoid it.

What we are trying to accomplish:

  • We want to update an entity (Archief - campagne) with information from the linked entity (Campagne activiteit).
  • The challenge is that an Archief - campagne can have more than one Campagne activiteit. But to ensure that the information is taken over correctly we only link 1 entity at a time.
  • To make this work we have created a formula to decide which enity is created first, based on the linked contact. So for every contact there is a first campagne activiteit.
  • So far so good.

The problem

  • When the Campagne activiteit is linked to the Archief - Campage, we trigger an automation to take over the specified information:

  • At the end of the automation we delete the linked Campagne activiteit → This one is no longer needed.

  • If the contact has more than 1 Campaign activity, the formula indicating which linked campaign activity was created first goes to true on the next Campaign activity (since the previous one was deleted) and the automation to take over specified information should run again.

  • And again, and again, and again. Till there are no more Campaign activiteiten left.

  • But no matter what we try to do, the aumation failed at the point where the Campagne activiteit is being deleted.

Since I don’t understand why this is happening I can’t solve this challenge. In my mind, it shouldn’t be a issue, because the entity linked, which causes the automation to being triggered, is being deleted at the end of the automation. And than a new entity, with a different ID, is being linked.

We have tried different ways of deleting.

  • By updating the Archief - Campagne, so we are able to delete the linked Campagne activiteit in a seperate automation.
  • By updating the linked Campagne Activiteit, so we are able to delete this item in a seperate automation.
    But the loop remains.

Can you please help us out.


P.s. Chris is you are the one to respond, please let me know if you would like the direct link to our workspace with a test setup prepared, so you can have some trial and error for yourself.

Hi @Marloes ,
Based on what you have described, the loop detection mechanism is working as it is designed to do. In your case, the automation gets triggered (for a specific Campagne activiteit calculated from the formula) and then when it is done, the formula gets recalculated and the automation is triggered again.
Although in practice there will be a finite number of times the automation might get triggered (= the total number of Campagne activiteit entities) the automation cannot know this in advance, and must assume that a repeating automation might theoretically run forever. It detects a loop and disables the automation.

From what you’ve said, I wonder why you are using an automation to increment the various numerical fields:
This would presumably be possible by just using formulas, calculated on the collection of Campagne activiteit entities, e.g. Campagne activiteiten.Sum(Open)
Admittedly, aggregating rich text contents from a collection is a bit harder, but maybe you could get away with using a feed view instead…?

Perhaps there is a reason why you want to delete the Campagne activiteit entities after they have been processed (and thus a collection aggregation would not work)?

Hi Chris,

This is indeed the case. We need to remove those Campaign activities because otherwise we will be over the 300,000 entities very quickly. In the Archive campaign, after half a year or so, we combine the data from the Campaign activities.

Is there any way you can think of to avoid the loop?

In adition. You say

  • When it’s done, the previous linked entity is being deleted. So no entity is linked to Archief - Campagne anymore.
  • Only then the formula gets recalculated. This causes the automation to link a different entity to the Archief - template.

Shouldn’t the system recognize that it is a different entity → because different public id → so it’s not a loop?

Loop detection doesn’t care if the automation is being re-triggered on the same entity or on a different entity. It just cares that the same root cause has led to the automation being triggered repeatedly.

How often do new Campaign activities get linked, and how soon after does the Archief need to be updated? You could have a scheduled trigger that operates once, on the current Campaign activity. If it was set to run every hour, then as long as there are no more than 24 new activities a day, you would have no backlog (but you would have a latency in updates).

1 Like

That’s a smart idea :smile:

Our clients have email lists with a few thousand persons on it. During a launch or due to automated funnels, it can be possible that they email more than once a day. We currently log all email/campaign activities.

When an email has send >183 days ago, we archive the campaign activities per contact. Currently that’s decided via a formula that triggers the automation. So all entities are linked when Today is updated during the night.

It’s not time sensitive when an email is archived. We only do it to avoid performance issues when databases have 300k entities.

So if I run the automation on schedule, this will be fixed I think :smile:

I want to run them outside normal office hours to avoid performance issues. But if I schedule them 3-4 time in the night I think that’s enough and there will not be a backlog. Or just 2 times a day since nobody will continuously email >1 per day.

Simple example:
State called Testing. Cards come into testing when there is nothing in testing, and something in the pre-testing state. There’s a formula to track if there’s anything in testing.
If something automatically takes a card out of testing, then something goes in, the field that tracks when there’s cards in pretesting 1 → 0 → 1, something detects a loop and the whole thing falls over. This isn’t the one that causes the most issues, but it’s the most straightforward one.

To check my understanding…

You have some umbrella entity, e.g. Project, which has a collection of linked Tasks. Some of the Tasks are in Pretesting state. If no Tasks are in the Testing state, then one of the Tasks that are in Pretesting should be automatically changed to Testing state.

Is that right?

What do the existing formulas/automations look like?

Yep. Currently they’re checking a field on the Project to see if that is 0 and a checkbox on the Tasks that for simplicity can be First In Line is checked. It triggers when Tasks in Testing changes. When [First In Line] and Project.[Tasks In Testing] = 0, the rule says to move the Task to Testing. There’s other rules that sometimes automatically remove tasks from testing (entirely tested, etc.). It only seems to fall over when a task is automatically moved out of testing and a new one put in.

How is the field ‘Tasks in Testing’ calculated?

The Project has Tasks.Filter(State.Name = “Testing”).Count()

The Tasks have a formula that looks at that that. At some stage someone has made the formula default to 1 for any Task that isn’t in a pre-testing state, but not sure if that has helped or not. It hasn’t fallen over very recently, but I suspect that might be because automations elsewhere were turned off for knocking it over so often. Hard to tell when you don’t know what the rules triggering things are.

What do you mean by this? Do you mean that there are multiple automations and you don’t know which one caused a value to be updated…?

Yup. Specifically I’m unsure which automation will have been the original trigger for the first Task being moved out of testing which seems to be part of what makes the loop detection grab it.