We’ve just released a new template designed to help you plan and monitor financial transactions.
Hope it is useful. Please let us know what you think.
7 Likes
Hi, could you please give a link for any tutorial to get familiarize with a new feature capabilities?
Hi, Andrei!
It’s not a new feature, but a template 
You can install it anytime
And inside there will be an explanatory document 
Hi, Polina. Could you tell me whether i need admin rights to install Finance template to get understand the possibilities?
Yes, only admins can install Templates
I was told that i have the opportunity to create my own Fibery. that 1 user account is free of charge. To check all possibilities of Finance module. Could you help me with it?)
In this case just register new account and install the template in it.
The template has been updated.
Due to changes in the way that ‘loop detection’ works, the automations for recurring transactions had broken.
The revised template can still create recurrences, but it no longer links recurring transactions together in a chain, so changes to the original do not get reflected in subsequent transactions.
Can you summarize how loop detection works, so we can avoid triggering it in our scripts?
1 Like
Loop detection exists to prevent the automation/formula services from being stuck performing continuous, never-ending updates.
It works by disabling an automation or formula if it detects that there has been some form of repeating.
For example, say you have a script that triggers when an entity is created or updated, and one of the actions is to update a field. If this field is then used in formula, which happens to be one of the fields that can trigger the automation, then there is the potential for the automation to be repeatedly triggered.
There’s nothing peculiar to scripts that will necessarily trigger loop detection. The principles apply whether an automation is running script actions or any other actions.
In the case of the original finance template, there was a formula field that would indicate where a transaction was in a particular series - basically an index number.
If the index of the last transaction in the series was less than some desired number, a new transaction would be created, and the index for this transaction calculated.
This new transaction would now be the last in the series, and if its index was still less than the required number, then the automation would run again. And so on…
In practice, there would be a cap on the number of times the automation would run, but the loop detection could not determine this, and a repeating automation is a trigger that will cause the automation (or the related formula) to be disabled.
My 5 cents to Chris’s answer above.
At the moment it works in the following way (some low-level details here):
A key is calculated for each action you use in a Rule.
It includes rule id, action name and entity id, for which action is called.
For “create” action there is no entity id of course, as we are creating new entity.
For “script” action key includes entity id as well.
Then the following rule applies:
If during a chain of changes, that are triggered by a rule’s actions, the same key is detected, this leads to a “loop”.
Example of chain of changes: you changed some field (field1) –> rule1 is executed and changed other field (field2) –> formula is recalculated as it relies on field2 –> rule2 is executed as it subscribes to formula field and this rule2 changes field1 –> loop is detected, as rule1 is executed for the same entity for the second time.
One more example.
Let’s say you have a rule, that subscribes to entity creation, and as an action it creates new entity of the same type.
First time you’ve created an entity we remember ‘RuleId1_CreateAction’ key. Then same rule is called as a reaction to entity creation, keys do match, and loop is immediately detected.
Current implementation means, that you cannot create a rule, that produces a chain, where this rule is triggered several times on the same set of entities, but eventually stops, by some user-defined termination condition (let’s say some filter in a Rule, or condition in action’s script). Instead, rule will exit with a loop on first repetition.
1 Like
I understand the principle - I was hoping for more details about the “how”.
For example I have some “trim blanks” Automations on text fields that are triggered on field updates; these scripts can update the same field. That could trigger loop detection, but in the past it has not done so (thankfully).
In this case I avoid a loop by having the script only update the field if it needs to be changed (i.e. blanks have been trimmed); so if an update does re-trigger the Rule, the subsequent run will not change it again.
I was wondering if there is anything I can learn about the technical aspects of how loops are being detected, so I might avoid having Automations like these disabled. 
1 Like
I think in the example you gave, it is self-limiting, because if the action does not actually result in any changes (i.e. there is no difference between ‘before’ and ‘after’) then there will be no retriggering.
In my case I expect the script to re-trigger its own Rule when it updates the field with a modified (trimmed) value.
This should run the script a second time, but in this execution the text field will not be modified (because it has already been trimmed), so that is the end of the self-triggering loop.
In your case loop should be detected as per algorithm I’ve described above.
(Un)Fortunately there is a bug in current implementation, that breaks loop detection for operations called from js scripts. So if you make a change from JS script, that chain I’ve described above is broken and starts anew.
Some day I will fix it and your rule will break 
For scripts we can improve though, and check actual fiberyApi calls from scripts, if they are duplicated in a chain. Cannot promise anything concrete here. When I’ll dig into the issue above, I’ll think deeper how to make scenarios like yours available.
@Sergey_Truhtanov
Suggestion: keep an “entry count” for each key, and allow 2 or 3 entries instead of just 1.
2 Likes
Agree to some extend. That will unblock many of current not possible scenarios, but still do the job of preventing infinite loops. But requires some effort, that’s why I haven’t done it from the beginning.
1 Like
If I could get any one change from Fibery, this would be it.
I have a few automations where it’s easier to just turn them back on every time they run (because they loop exactly once) than it is to do things manually.
2 Likes