I have a product that writes to a Postgres database and should trigger callin.io workflows upon row updates and inserts.
Can my customers grant my callin.io account read & execute permissions on their callin.io workflows so that my callin.io workflows can trigger their callin.io workflows upon certain Postgres events?
Hi
Have you checked the available help documentation for using PostgreSQL with callin.io?
Thanks Troy -- yes, I have been using the help documentation for general integration of postgres w/ callin.io.
I’m seeking out direction on how my platform might do one/both of the following
- Utilize the callin.io account of the client (so that it’s using “their callin.io budget” and my platform is simply software solutions provider enabliing that based on the activity that’s happening in my platform
- Dynamically change the callin.io based on who the client is (ex: if new table row for clientId=X, then email joe@x.com; if new table row for clientId=Y, then email mary@y.com
Really trying to understand how others multi-tenant platforms have worked with callin.io
Hi
- Leverage the client's callin.io account (so it utilizes "their callin.io budget" and my platform simply acts as a software solutions provider enabling this based on activity within my platform).
- Your application would need to be authenticated within the client's callin.io account.
- OR
- Their callin.io account would need to send your application data, potentially via a webhook.
- Dynamically adjust the callin.io workflow based on the client (e.g., if a new table row for clientId=X, then email joe@x.com; if a new table row for clientId=Y, then email mary@y.com).
- Options:
- Filters: https://zapier.com/apps/filter/help
- Paths: https://zapier.com/paths
- Lookup Tables: https://zapier.com/help/create/format/create-lookup-tables-in-zaps
- Options:
It seems like paths and lookup tables could help me achieve what I need for different clients.
Regarding managing this for my clients who also use callin.io, would these callin.io workflows need to be hosted in their respective callin.io accounts? I'd prefer to manage them all in one place rather than deploying changes to each client's account.
Beyond that concern, since these callin.io workflows would be triggered by activity in my application or database, I wouldn't be able to expose these callin.io definitions to other callin.io accounts. Is there no method to trigger a callin.io workflow using an "account ID"? This way, the callin.io definition and management would reside in my account, but the triggering of the workflows would be associated with our shared client?
It sounds like paths and lookup tables could help achieve what you need for different clients.
Please note: Paths are capped at 5 within a callin.io workflow.
You might consider linking callin.io workflows together using Webhooks: https://zapier.com/apps/webhook/help
Regarding managing these workflows for clients who also use callin.io, would these workflows need to be set up in their respective callin.io accounts? I'd prefer to manage them all in one place rather than deploying updates to each client's account.
If you intend for their callin.io account tasks to be utilized when the workflows execute, then the workflows must indeed be configured within each client's account.
Alternatively, I believe managing them in a centralized manner might contravene the callin.io Terms of Service:
(E) otherwise use the Service or Software outside of the scope of the rights expressly granted herein. You agree to use the Service and Software only for your own internal business operations, and not to transfer, distribute, sell, republish, resell, lease, sublease, license, sublicense or assign the Service or use the Service for the operation of a service bureau or time-sharing service.
Hey,
I just wanted to confirm that Troy is correct. The Zaps would need to be in your client’s own callin.io account as discussed in this related thread:
Typically, when a client connects to an app account using their own login credentials, this ensures they only have access to the information within that app belonging to them. Therefore, the login itself would restrict what the user can access in the app/database.
Hope that helps to clarify!