It appears that fibery.createEntity() creates a new entity initially without the specified fields content, and then after some time the entity is updated with the fields content specified in createEntity.
I say this because I have a script that does this:
fibery.createEntity( 'Page', {Name, 'Is Template': true} )
I have a separate Rule that triggers when a new Page entity is created – but this Rule has a filter which should prevent it from triggering in this case, because in this case the entity is being created with {'Is Template': true} –
And yet, this Rule runs immediately after the other script creates a new Page entity, which implies that the fields specified in fibery.createEntity() were not yet set… because if they had been set, the Rule’s filter should have prevented it from running. 
Or am I missing something?
This would be quite inconvenient, because It would mean that a Rule triggering on “entity created” cannot distinguish whether an entity is still being created – its filters are useless.
Hello.
That should not be the case. fibery.createEntity works just like you’ve described, creating entity with all the fields at once.
Could you please share more info: workspace name, both rules that cause the issue (names will be enough) and entity for which this setup did not work correctly(“public id” would be good).
Btw, I’ve checked similar setup on my account, and filter works as expected.
Info sent in Private Message.
Dig into details and here is an explanation(just sharing it for everybody):
Filter in Automation Rules do not run on a state at the moment of a change, that caused Rule’s trigger. Instead, they run on a live state at the moment of a Rule run. So there is a delay.
First your script performs a change.
Then some time passes and Rule Engine receives an event about this change.
At that moment Rule Engine performs query to Fibery Api to check if Entity corresponds to a Filter.
This query is performed on a live data, and Entity may be changed in time interval from the change and to time when event is processing by a Rule Engine.
We don’t proud of this behavior, but consider it as a compromise, as we wanted to support powerful Filters for Automation Rules. We didn’t get much complains on this behavior over years, so at the moment we stick with it.
1 Like
Thanks @Sergey_Truhtanov.
This essentially means that we cannot reliably use filters on an “entity created” Rule to distinguish whether a new entity has been modified since its creation.
Other processes (including the one creating a new entity) can modify a new entity before a “when created” Rule is triggered for it.
This actually makes sense, because you could have many Rules that trigger on “entity created” for a DB, and they can’t ALL be first. 
My workaround is to add a new field to the DB, to help Rules know which entities to ignore.
For example in my cloneable DBs I added a Text field called “Rules”. When my cloner script creates a new entity, it puts the string “[CLONE]” in this field. This can then be detected by the other Rules which run on entity creation with the filter: [Rules] contains "[CLONE]" (or the inverse, to avoid processing cloned entities).
2 Likes
