This topic was automatically generated from Slack. You can find the original thread here.
Hi @U02A06JPKEH @U05FUC30Q01, i have a workflow that triggers when a new message on slack comes. I want use this workflow for my external users, what are the ways to activate this for my external users?
CC:- @U095D9MBG49 @U094Y8Z67C4
To activate your Slack-triggered workflow for your external users, you have a couple of main options with Pipedream Connect: ### 1. HTTP Webhook Trigger You can expose your workflow as an HTTP endpoint (webhook) that your external users can call. This is a flexible way to let external users (or their systems) trigger your workflow directly, regardless of their Slack access. - How it works: - Set up an HTTP trigger in your workflow. - Share the webhook URL with your external users. - When they send a request to this URL, your workflow runs. ### 2. Deploy an Event Source (like Slack) for Each User If you want your workflow to react to Slack events (like new messages) from your external users’ own Slack workspaces, you can deploy a Slack event source for each external user. - How it works: - Each external user connects their Slack account to your Pipedream workflow. - You deploy a Slack trigger (like “New Message In Channels”) for each user. - Your workflow runs when a new message is posted in their Slack. ### Reference From the Pipedream Connect documentation: > You have two options for triggering workflows that run on behalf of your end users: > 1. Invoke via HTTP webhook > 2. Deploy an event source (Slack, Gmail, etc.) ### Next Steps - Decide if you want your users to trigger the workflow via HTTP (option 1), or if you want to connect to their Slack directly (option 2). - For Slack-based triggers, you’ll need to onboard each external user to connect their Slack account to your workflow. If you need more details on either approach, or have a specific use case in mind, let me know!
when i deploy and event source can i add extra variables in payload that can be utilized by my workflow. lets suppose that the I deployed an event source for a new mail for my external user and i want this event source to be connected to my workflow that takes an custom token.
Yes, you can add extra variables (custom properties) when deploying an event source (trigger) via Pipedream Connect, and these can be accessed in your workflow. ### How it works When you deploy a source (trigger) using the Connect API, you provide a configured_props object. This object can include any custom properties your workflow (or the component) is designed to accept. For example, if your workflow expects a custom token, you can include it in the configured_props payload when deploying the source for your external user. #### Example payload (from the docs): on { "external_user_id": "abc-123", "id": "gmail-new-email", "configured_props": { "gmail": { "authProvisionId": "apn_kVh9AoD" }, "customToken": "YOUR_CUSTOM_TOKEN_VALUE" }, "webhook_url": "https://events.example.com/gmail-new-email" } - Here, customToken is your extra variable. - Your workflow can reference this value as a prop if the trigger/component is set up to accept it. ### How to use in your workflow 1. Define the prop in your component (if you’re building a custom source/component): export default defineComponent({ props: { gmail: { type: "app", app: "gmail" }, customToken: { type: "string", label: "Custom Token" } }, async run({ steps, $ }) { // Access the custom token const token = this.customToken; // ... your logic } }) 2. Deploy the source with the custom property as shown above. 3. Access the variable in your workflow using this.customToken (or whatever name you use). ### Reference From the Pipedream Connect Components documentation: > When deploying a source, you can define either a webhook URL or a Pipedream workflow ID to consume those events. Deploying a source is done by sending a payload similar to the one used for running an action, with the addition of the webhook URL or workflow ID. > The response will contain … all the component’s props metadata, as well as their values. Summary: You can pass extra variables (like a custom token) in the configured_props when deploying an event source, and your workflow can access them as props. If you need more details or a code example for your specific use case, let me know!
did you deploy the trigger via the API?
Thanks
@U05FUC30Q01 @U02A06JPKEH To connect a workflow to a trigger, I see two possible approaches:
workflowId: In this case, the trigger is directly associated with the workflow upon deployment. However, the downside is that I’m unable to pass any custom props or parameters into the workflow at runtime.workflowId, and instead rely on the webhook URL to receive events, Here, the trigger captures the event and then invokes the workflow through an HTTP-based trigger, allowing all required parameters to be passed dynamically.also if there is any other method that i am missing.
Certainly! Here’s a comparison of the two approaches for connecting a workflow to a trigger in Pipedream Connect, including their pros and cons: — ### 1. Deploy the trigger with a workflowId How it works: You specify the workflowId when deploying the trigger via the Connect API. The trigger is directly linked to the workflow, and events from the trigger automatically run the workflow. Pros: - Simplicity: Direct association—no need to manage webhooks or additional routing logic. - Less plumbing: Pipedream handles the event delivery to the workflow for you. - Consistency: The workflow always receives events in the same format. Cons: - Limited dynamic configuration: You cannot pass custom props or parameters into the workflow at runtime for each event/user. The configuration is fixed at deployment. - Less flexibility: If you need to customize the workflow execution per event (e.g., pass a token or user-specific data), this approach is restrictive. — ### 2. Deploy the trigger without a workflowId (use webhook URL) How it works: You deploy the trigger without specifying a workflowId. The trigger emits events to a webhook URL you control (e.g., an HTTP-triggered Pipedream workflow). You can then process the event and invoke any workflow, passing custom parameters as needed. Pros: - Maximum flexibility: You can pass any parameters (tokens, user IDs, etc.) to the workflow at runtime. - Dynamic routing: You can decide which workflow to invoke, or how to process the event, based on the event data. - Custom logic: You can enrich, filter, or transform events before invoking the workflow. Cons: - More complexity: You need to manage the webhook endpoint and handle event forwarding yourself. - Potential latency: Additional HTTP hop may introduce slight delay. - More moving parts: Slightly more to maintain (webhook workflow, event forwarding logic). — ### Summary Table | Approach | Flexibility | Simplicity | Dynamic Params | Maintenance | |-------------------------------------------|-------------|------------|---------------|-------------| | Deploy with workflowId | Low | High | No | Low | | Deploy without workflowId (webhook URL) | High | Medium | Yes | Medium | — ### Recommendation - If you need to pass custom parameters or dynamically control workflow execution per event/user, use the webhook URL approach. - If you want the simplest setup and do not need dynamic parameters, use the workflowId approach. For more on deploying event sources and connecting them to workflows, see the Pipedream Connect documentation. If you have a specific use case or need help with implementation, let me know!
on this approach
Deploy the trigger with a workflowId: In this case, the trigger is directly associated with the workflow upon deployment. However, the downside is that I'm unable to pass any custom props or parameters into the workflow at runtime.
Can you share some more light how configure props can be passed to workflows? some examples would be appreciated.
When you deploy a trigger with a workflowId in Pipedream, you can pass configurable props (parameters) to the workflow, but these are set at the time you create (or clone) the workflow—not at runtime per event. Here’s how this works and some examples: — ### How configurable props are passed to workflows 1. Identify configurable props - Each trigger and step in a workflow can define “configurable props” (parameters you can set when creating the workflow). - You can find these by inspecting the workflow template or using the Get Workflow API. 2. Set props when creating the workflow - When you use the Create Workflow API, you can provide values for these props in the payload. - These values are “baked in” to the workflow instance and used every time the trigger fires. #### Example Suppose you have a workflow template with: - An RSS trigger that takes a url prop. - A Slack step that takes channelId and message props. You can create a new workflow instance with specific values for these props: on { "project_id": "proj_abc123", "org_id": "o_abc123", "template_id": "tch_abc123", "triggers": [ { "props": { "url": "https://hnrss.org/newest?q=Pipedream" } } ], "steps": [ { "namespace": "send_message", "props": { "channelId": "C123456", "message": "New item posted!" } } ] } - The RSS trigger will always use the specified feed URL. - The Slack step will always send to the specified channel and message. — ### Key points - Props are set at workflow creation time (not per event). - You cannot change these props dynamically at runtime for each event when using the workflowId approach. - To set different props per event, you’d need to use a webhook trigger and pass data in the HTTP request body. — ### Docs references - Design the payload - Get Workflow API - Using props in code steps — Summary: You can pass configurable props to workflows when you create them via the API, but these are static for that workflow instance. For dynamic, per-event parameters, use a webhook trigger and pass data in the request. Let me know if you want a code example or more details on a specific use case!
need some examples for configuring props for a gmail new email received trigger deploying that takes custom token as prop and external user id and workflow id. so that workflow can utilize external user id and custom token.
Certainly! Here’s how you can configure props for a Gmail “New Email Received” trigger in a Pipedream workflow so that you can pass and utilize a custom token, external user ID, and workflow ID. — ## 1. Defining Custom Props in the Trigger When you create a custom trigger (or clone an existing one), you can add custom props to accept values like customToken, externalUserId, and workflowId. Here’s an example of how you might define these props in a custom component: export default defineComponent({ props: { gmail: { type: "app", app: "gmail", }, customToken: { type: "string", label: "Custom Token", description: "A custom token to use in the workflow", }, externalUserId: { type: "string", label: "External User ID", description: "The external user ID to associate with this workflow", }, workflowId: { type: "string", label: "Workflow ID", description: "The workflow ID for tracking", }, }, async run({ steps, $ }) { // You can now use these props in your workflow $.export("customToken", this.customToken); $.export("externalUserId", this.externalUserId); $.export("workflowId", this.workflowId); // Example: Get Gmail user info const { axios } = require("@pipedream/platform"); const userInfo = await axios($, { url: `https://www.googleapis.com/oauth2/v1/userinfo`, headers: { Authorization: `Bearer ${this.gmail.$auth.oauth_access_token}`, }, }); return { userInfo, customToken: this.customToken, externalUserId: this.externalUserId, workflowId: this.workflowId, }; }, }); — ## 2. Passing Props When Deploying the Workflow When you deploy or instantiate the workflow (e.g., via API or UI), you can set these props. For example, via the REST API: on { "project_id": "proj_abc123", "org_id": "o_abc123", "template_id": "tch_abc123", "triggers": [ { "props": { "customToken": "my-secret-token", "externalUserId": "user-123", "workflowId": "wf-456" } } ] } — ## 3. Using Props in Workflow Steps In subsequent steps of your workflow, you can reference these props via steps.trigger.event.customToken, steps.trigger.event.externalUserId, etc. Example code step: ```
export default defineComponent({ async run({ steps, $ }) { const customToken = steps.trigger.event.customToken; const externalUserId = steps.trigger.event.externalUserId; const workflowId = steps.trigger.event.workflowId; // Use these values as needed return { customToken, externalUserId, workflowId, }; }, });
I briefly caught up w/ on this — @U094SL220Q2, it sounds like you’re trying to deploy an event source trigger that runs on behalf of your users, which will invoke a Pipedream workflow when the trigger emits, right? And you’re wondering how to get additional configuration data into the workflow so that you can execute other steps on behalf of that user?
Probably the best way to do that right now would be to either store whatever config data you need in a Pipedream Data Store, or if you have it stored outside of Pipedream, you can query that database as a step within your workflow.
Would that work?
thanks