Please implement drag-drop sorting of Rules (similar to drag-drop sorting of Access Templates), that is the first minor improvement that the Rules UI can have. Tagging and linking Rules would be the next step after that, thus making Rules entities.
========
Note: With the introduction of Highlights, the next logical step is to make Fibery support better workflows to create and make use of that data.
I think there are three core features of Fibery that drive cycles of intelligent input and output:
Data: Highlights
Processes: Automations (workflows)
Insights: AI Workspace Data Expert
The Automations feature is in my opinion underdeveloped at this stage.
i agree that drag and drop for rules would improve the user experience. I am interested in your opinion on automations, what are the features that are currently missing in your opinion? What kind of use-cases are you looking to implement using automations. An example or two would be very helpful
Thank you for posting this. Had this in my feedback list too. As I have many rules in one of my databases, a simple reorder feature and maybe something like folders for sorting certain automations would be a big quality of life improvement.
Also, the features @interr0bangr mentions are welcome. While IF-statement implementation will be not that easy, cloning and duplicating would add great comfort of use.
I am not sure what you mean with delaying the automation executions. As far as I know, formulas and rules are using async functions, so they normally would not cause any conflicts. Personally, I dināt encounter any, but a demonstration / example would be great. Maybe I am wrong here.
Maybe Iām misspeaking because Iām not sure exactly how the loop detection works, but sometimes I want to trigger an automation on a formula-based checkbox where one of the steps may update the checkbox itself and thereās a filter to try and prevent the loop, but because the checkbox isnāt updated in time to stop the loop it fails.
I figured a delay of 10 seconds or something between loops might help in those cases.
Another use case for a delay would be if a rule is triggered by accident (for example, a taskās state is changed from āIn Progressā to āCompleteā, but the user realizes a few moments later that it should still be āIn Progressā and changes the state back), there could be a grace period that could stop a further step from happening if the trigger criteria is no longer met.
Iām used to using Hubspot workflows and they do delays and conditional branching really well.