Why Does PD Default to the Last Authorized Account in the Same Application Integration and How Can This Issue Be Resolved?

Help
1

This topic was automatically generated from Slack. You can find the original thread here.

I encountered a problem: why does PD default to setting the last authorized account of a user’s same application integration as the default? In our system, users can switch authorizations, so this makes no sense, as PD defaults to using the last account as the authorization. How can this issue be resolved?

2

Could you share a screenshot?

3

In what context are you referring to? What default behavior do you think would make more sense?

4

is the issue depicted in Picture 1. We hope to be able to notify PD through parameters, informing it which account of the user should be authorized at the moment. For example: On my platform, a user links to Notion and authorizes 3 accounts. During this request, if there is a parameter that allows me to pass to PD to inform it to use the authorized account B in this instance. This would be more reasonable. Because of the comment content in the document, in our product, we save the 3 Notion accounts authorized for this user as 3 different users to achieve the capability we want, but doing this will cause PD’s usage volume to increase rapidly. I suggest that a certain application’s account under a user should be used as a parameter to map to this user, so that the user remains unique. However, we currently have to allow users to have several Notion accounts, and we create several corresponding users as shown in Figure 2. This is how we handle it now. This means that a user has several applications, and each application has several accounts. We need to create several users for PD. Perhaps we haven’t found the correct method. Do you have any suggestions for us? cc @U02A06JPKEH

image.png
image.png3372×1762 640 KB

img_v3_02pq_8b5e2fbe-7053-43c1-9e08-5a425ee8829g.jpg
img_v3_02pq_8b5e2fbe-7053-43c1-9e08-5a425ee8829g.jpg2530×1078 141 KB

5

What part of the Connect product are you using? Are you triggering Pipedream workflows? Running actions via the API / SDK? MCP?

6

We use the SDK to handle authorization and user management. When our own Agent component invokes tools, it uses the PD MCP

7

Check out the accountId param or x-pd-account-id header: Develop with Pipedream MCP - Pipedream

8

Thanks, I saw that (ps: I should read the documentation more carefully next time):melting_face: