We’re developing an app that adds custom triggers and actions to Shopify Flow, and I have a couple of feature requests:
I noticed that in the standard triggers and actions, there’s an “i” icon next to the item description, which links to the documentation page. Would it be possible to add a similar button for third-party app actions and triggers, so that we can provide a link to our documentation in the descriptor of the action/trigger?
Our app has a mechanism for launching workflows that start with a custom trigger. These triggers can be fired in different ways: from another workflow, via an HTTP request, or from the UI. Since these triggers allow users to break down large workflows into smaller reusable parts, they’re used quite frequently. Currently, for third-party apps, it’s only possible to trigger all workflows that start with a specific trigger — there’s no way to launch a specific workflow. So, users add a condition right after the trigger to filter by a trigger field, meaning that all workflows start, but only one continues while the others exit immediately.
My question is: does this behavior affect the client’s rate limits, given that dozens of workflows are technically being started (even if they terminate right away)?
If it does have an impact, could you consider adding support for launching specific workflows for third-party apps?
Hi @Yuri_K - thanks for reaching out, I definitely agree with your first request there, it does makes sense for us to enable documentation links for third party Flow actions, similar to how we link to the Shopfiy documentation for our internally created Flow actions for sure. I can’t guarantee a timeline or if the feature will be implemented, but I’ve gone ahead and officially logged a feature request for you for that first question.
For your second question there, hopefully I’m understanding correctly, but you’re wondering about rate limits for the client app that’s initially receiving the request from Shopify Flow to carry out the triggered action?
Regarding the rate limits, the flowTriggerReceive mutation itself only counts once against your app’s API rate limit, but the execution of those multiple workflows using the same trigger (even the ones that terminate immediately due to your conditions) does count against the Flow execution limits.
I can definitely see how being able to target specific workflows would be valuable for your use case of breaking down large workflows into smaller, reusable components. I’d be happy to log this as a feature request as well. Could you share a bit more about how many workflows typically share the same trigger in your implementation, and how you’d ideally like the API to work if you could target specific workflows? This will help me advocate more effectively with our Flow team.
Thank you for getting back to me with such a thorough analysis of my message.
I’ve gone ahead and officially logged a feature request for you for that first question.
Thank you! There’s no urgency regarding this request. I just believe it could be very helpful for users if they could navigate directly to the documentation page from the trigger/action panel in a workflow.
The second question arose from a message sent to our support team by one of our customers. They reported receiving the following message when bulk-starting workflows:
This led us to suspect that the current trigger initiation implementation might be contributing to the load our app places on Shopify Flow.
how many workflows typically share the same trigger in your implementation
We don’t have that kind of statistic, since Shopify Flow doesn’t provide us with tools to track it (at least, not to my knowledge). But I’ll ask the customer who submitted this support request and follow up with you in a direct message, as the information might be sensitive for the client.
how you’d ideally like the API to work if you could target specific workflows
Here’s how I imagine an ideal implementation:
The trigger would support configuring execution parameters for a specific workflow. In my use case, this would be a Specifier string parameter where the user could enter a value.
Before starting a particular workflow, Shopify Flow would send a request to our app (similarly to how it does when executing actions). This request would include both the parameter values configured in the workflow for this trigger and the payload from the flowTriggerReceive mutation.
Our app would compare the parameter value from the workflow configuration with the value from the flowTriggerReceive payload, and return to Flow Companion whether the workflow should be started or not.
If the flow_trigger_lifecycle_callback callback included information about the trigger parameters, we could even avoid calling the flowTriggerReceive mutation in cases where there is no active trigger with matching parameters.
Such a solution would also allow us to:
Collect statistics on trigger usage
Detect and prevent infinite loops by interrupting workflow execution. This could occur if a user triggers the same workflow from within itself.
Thanks for the details on this @Yuri_K - very much appreciated. I can’t guarantee anything on my end here in terms of if/when the features would be implemented, but I did just want to follow up here to let you know that I’m definitely happy to log this on our end as a feature request.
I’ll include your implementation details in the feature request since I think your idea related to the statistics collection and infinite loop detection capabilities would be valuable additions too.
The customer usage data you mentioned would be helpful context when you have a chance to share it, even via DM as you suggested. No rush on that though - please feel free to ping me here in the thread once you have that from them and I can set up the DM.
Once I hear back from you and we set up that DM, I can close out the thread just for tracking on our end. Hope to hear from you again soon!
