This topic was automatically generated from Slack. You can find the original thread here.
is it possible to filter a trigger so only certain trigger events start the workflow
Yes, it is possible to filter a trigger so that only certain trigger events start the workflow. You can use the Filter app in Pipedream to specify conditions that must be met for the workflow to proceed. If the conditions are not met, you can end the workflow early. Here is an example of how you can use the Filter app in a Pipedream component: import { axios } from "@pipedream/platform"; export default defineComponent({ props: { filter: { type: "app", app: "filter", }, }, async run({ steps, $ }) { let condition = false; // Replace this with your actual condition if (condition == false) { $.flow.exit("Ending workflow early because the condition is false"); } else { $.export("$summary", "Continuing workflow, since condition for ending was not met."); } }, }); In this example, you can replace the condition variable with your actual condition logic. If the condition is false, the workflow will end early. If the condition is true, the workflow will continue. For more information on using the Filter app, you can visit the Filter app documentation. If you need further assistance, feel free to ask!
but stopping the workflow would still have meant the workflow cost 1 x credit?
You should visit Pricing - Pipedream for the latest pricing, but I’ll do my best to answer. Yes, stopping the workflow would still mean the workflow cost 1 credit. Pipedream charges one credit per 30 seconds of compute time at 256MB of memory per workflow execution. Most workflow executions use a single credit, regardless of the number of steps. For more details, please see the Pipedream pricing page.
I have a trigger that will trigger 5 times for every time i need to use it. i want to pay 1c for when i need it not 5c everytime. how?
To help you reduce the number of times your trigger fires and thus reduce your costs, you can implement a deduplication mechanism or a rate-limiting strategy within your Pipedream workflow. Here are a couple of approaches you can take: ### 1. Deduplication Using Data Stores You can use Pipedream’s Data Stores to keep track of the events that have already been processed and avoid processing duplicate events. Here’s an example of how you can do this: import { axios } from "@pipedream/platform"; export default defineComponent({ props: { data: { type: "data_store" }, }, async run({ steps, $ }) { const eventId = steps.trigger.event.id; // Assuming each event has a unique ID const processedEvents = await this.data.get('processedEvents') ?? []; if (processedEvents.includes(eventId)) { return $.flow.exit('Event already processed'); } // Add the current event ID to the list of processed events await this.data.set('processedEvents', [...processedEvents, eventId]); // Your main logic here // ... return "Event processed successfully"; }, }); ### 2. Rate Limiting Using Delay You can also implement a delay to ensure that your workflow only processes events at a certain rate. This can be useful if you want to limit the number of times your workflow runs within a specific time frame. ```
import { axios } from “@pipedream/platform”; export default defineComponent({ async run({ steps, $ }) { const delay = ms => new Promise(resolve => setTimeout(resolve, ms)); // Delay for 1 second (1000 milliseconds) await delay(1000); // Your main logic here // … return “Event processed after delay”; }, });
the trigger is “order edited” on shopify but I only want to use the instances where an order is refunded which is a small minority
To achieve this, you can use the “Order Edited” trigger for Shopify and add a filter step to only proceed when an order is refunded. Here’s how you can set it up: 1. Create a new workflow in Pipedream. 2. Add the Shopify “Order Edited” trigger: - Search for “Shopify” in the trigger search bar. - Select the “Order Edited” trigger. 3. Add a filter step to check if the order is refunded: - Add a new step after the trigger. - Select the “Filter” action. - Configure the filter to check if the order’s financial_status is refunded. Here is an example of how you can set up the filter step in a Node.js code step: export default defineComponent({ async run({ steps, $ }) { const order = steps.trigger.event; if (order.financial_status === "refunded") { // Proceed with your logic for refunded orders return order; } else { // Exit the workflow if the order is not refunded $.flow.exit("Order is not refunded"); } } }); In this setup: - The steps.trigger.event contains the order data from the Shopify “Order Edited” trigger. - The code checks if the financial_status of the order is refunded. - If the order is refunded, it proceeds with your logic. - If the order is not refunded, it exits the workflow. This way, you ensure that only the instances where an order is refunded are processed further in your workflow.
but that that still fires the workflow every time an order is edited. which is 1c each time.
It sounds like you’re concerned about the cost associated with your workflow being triggered every time an order is edited. To help you manage this, you might want to consider adding a filter or condition to your workflow to ensure it only runs under specific circumstances. Here are a few strategies you can use to reduce the number of times your workflow is triggered: 1. Add a Filter Step: You can add a filter step at the beginning of your workflow to check if the order meets certain criteria before proceeding with the rest of the workflow. For example, you can check if the order status has changed or if a specific field has been updated. 2. Use a Conditional Step: Similar to a filter, you can use a conditional step to evaluate whether the workflow should continue based on the data in the event. 3. Debounce the Trigger: If your workflow is being triggered multiple times in quick succession, you can add a delay or debounce mechanism to prevent it from running too frequently. Here is an example of how you might add a filter step to your workflow: ```
export default defineComponent({ async run({ steps, $ }) { const order = steps.trigger.event.body; // Check if the order status has changed if (order.status !== “desired_status”) { // Exit the workflow if the condition is not met $.flow.exit(“Order status has not changed”); } // Continue with the rest of the workflow // Your existing workflow steps go here } });
FYI you can either modify the source yourself to add the order type as a prop, and only emit the events you care about (but you’ll still incur a credit for every source invocation), or if it might make sense for others, you can submit a feature request for our team to do that work on the registry source, which will allow you to only pay for when the source emits the events you care about.
I’ll try and edit the trigger myself tonight. Can you remind me where I see the base code for the trigger so I can make amendments? Thanks.
To clarify; a prop field on the trigger would act pre-workflow effectively, not post? So If I only emit refunds on the “update order” trigger only those refund events will count towards my credit total?
You can search through the public repo to find the existing component you’re looking for: pipedream/components at master · PipedreamHQ/pipedream · GitHub
Invocations from sources that are part of our public registry (ie, in that repo), do not incur a credit on their own, whether or not they emit an event — you only incur credits based on the workflow execution. However, custom sources that you modify do incur credits upon invocation. Check out our docs here: Plans and Pricing - Pipedream
So the custom source route wouldn’t help you avoid paying for source invocations on events that you don’t care about. But if it’s an event filter that’d broadly make sense for other Pipedream customers, you can submit a PR or feature request for our dev team to add it to the public source.
Does that make sense?
OK, looks like I have to go the trigger request route then. I think “update order” emits an event for every single update (approx 10-20 per order). I only need refunds specifically because I’m trying to build a store credit/rewards workflow so I need to debit store credit for any refunds. I hope that would have other uses for other people though - ie shipping, inventory etc.