👂 Feedback needed: scripts in automations that shouldn't be scripts

[Matt_Blais]

Sure - if some condition A, then return some filtered collection; else return empty.

[Chr1sG]

@Matt_Blais

if some condition A, then return some filtered collection; else return empty.

This can (usually) be done via

Collection.Filter(Condition A)

[Matt_Blais]

I might be mis-remembering, but when you have a DB with an auto-linked relation to another DB’s Public Id, a script is required to auto-vivify one whenever the other is created.

My recollection is that a script was required was because I couldn’t access Public Id via a Formula.

[Sergey_Truhtanov]

@Lee_Denny

UUID in a formula or auto

And can you please describe your use case?

[Chr1sG]

@Matt_Blais

when you have a DB with an auto-linked relation to another DB’s Public Id, a script is required to auto-vivify one whenever the other is created

I think this is not so much a formula issue, but more a side-effect of the fact that an auto-linked relation is read-only, so you can’t do the same things in automations that you can with a normal relation, e.g. add new entity

[Lee_Denny]

Two quick ones;

To create URLs with parameters to pre-populate fields in Fibery forms.

To make it easier to use Zapier to interact with any single select, multi select or relational fields all of which require using the UUIDs.

So much of the way Fibery works with external software requires UUIDs but you make it basically impossible to access them inside your product!

[interr0bangr]

I wish GraphQL was implemented universally across all databases in Fibery so it could be used in all scripts. Currently you can’t use it to query the Fibery/User database.

[Oleg]

Hello, @interr0bangr

Please use Fibery API which is implemented to be used universally. Please find more information here

[interr0bangr]

Thank you. We do use that when needed, would just prefer not having to mix & match APIs if it was at all possible and use GraphQL for everything.

[NicolSpies]

Works great
Only found one problem that needed correction.
The AI generated script referred to the start and end of date ranges as range.Start and range.End instead of range.start and range.end

[Quinn_JH]

Lee,

I recall solving an automation problem checking that an entity was created for each product of two types by spitting this value into an additional field called ‘api-id’ to be easily accessible. I would select all and run this script:

const fibery = context.getService('fibery');
for (const entity of args.currentEntities) {
    await fibery.updateEntity(entity.type, entity.id, {
        'api-id': entity.id
    });
}

As others have said, entity UUID’s are not unique across databases, but was not an issue for my app. Definitely seemed like I was “doing the wrong thing” here but didn’t care as it got rid of the friction - and allowed using the id from within formulas.
Maybe this is what you mean by “impossible to access”?

[YvetteLans]

We currently use scripts to copy files from one entity to another. Would be great if we can have a native solution for that as well

[mdubakov]

@YvetteLans

We currently use scripts to copy files from one entity to another

First, we want re-design files component and transform it to Files Field. Then we will do other things like that on top

[Lee_Denny]

Thanks for this idea, I dont see why UUID cant just be available in formulas without having to use this workaround though

[Sarah_Arminta]

I actually just tried the AI Script Assistant and it was very helpful! Thank you for making this!!

[mdubakov]

In the next release it will be available right near Script action in Automations.

[Matt_Blais]

If the script AI can create complex API queries, that will be an amazing time saver.
I have not played with it yet.

[tycecycle]

+1 on prior steps. Would be great to just simply grab the results without scripting.

@helloitse

Using the Outputs of Prior Script Steps

Do automation actions return step results? Can we use them further down the automation stack? Automations

[Illusory]

@interr0bangr

Formulas within automation filters! Would unlock so much more power and minimize many complex workarounds for things.

@interr0bangr

There’s no way to do auto-links with any other condition besides EQUALS, which means we often need to rely on scripts to link related entities for CONTAINS/IS ONE OF scenarios.

Agreed.

@interr0bangr

• There’s no way to do multiple/splitting paths (IF statements) in automations without a script.

100%. Or you must create multiple automation rules for small variations, which is a pain.

@interr0bangr

“ToNumber” function** (the opposite of the existing “ToText” function)

This one is big as well. Really need this.

@helloitse

Call a webhook/URL

One of the biggest for us, as I’ve already stated. POST is a priority. GET is a plus.

Excited to see what is implemented. Apart from improving the overall user experience when dealing with automated functions, Fibery eliminating more “workarounds” by providing direct integration with Automations will encourage users of the revived Free Plan to upgrade to the Pro Plan for enhanced automated features and limits.

[Matt_Blais]

Not exactly answering the question posed, but this is related, as it is about a missing Automations capability:

Ideally we could mark a Rule to execute for multiple matching entities Sequentially rather than in Parallel; i.e. the Rule must complete all its actions for one entity before it begins executing any actions for another entity.

My problem scenario: I have many subject entities that need to get linked by a Rule to an “aggregation entity” (by matching a date range), and if the appropriate aggregation entity does not exist for the required date range, then it gets created and linked.

This should be simple, but I can find no way to prevent a missing aggregation entity from being created multiple times, because the Rule appears to process multiple subjects in parallel (meaning Action 1 of the rule is executed “in parallel” for multiple entities before the remaining Actions have been completed).

It appears that when multiple entities match a Rule, up to 50 of them begin running the first Action(s) of the Rule before any of them have actually completed the entire Rule. So I have multiple entities deciding their aggregation entity does not exist, and they all proceed to create their own version of it, when only one should be created.