Skip to main content

Hi,

 

We’re evaluating Zapier to pass data back and forth between Salesforce and a custom

webapp backed by a PostgreSQL database.  The data flow would look like this:

 

Salesforce <=> Zapier <=> PostgreSQL webapp database (Flow A)

 

The data flows in both directions. 

 

But, the page “How to Get Started with PostgreSQL”   https://zapier.com/help/doc/how-get-started-postgresql

includes this text:

Note: all fields are stored encrypted in our database. Of course, we
have the encryption keys on hand but they are stored separately to minimize
risk. Nonetheless, we recommend not hooking a production database to
Zapier. Instead, set up an intermediary database to connect with Zapier
then dump data back to your main production database using some out-of-band
process.

 

My reading of this is that we shouldn’t let Zapier talk to the webapp production database at all.

Rather, the data flow should look something like this:

 

Salesforce <=> Zapier <=> PostgreSQL intermediary database <=> PostgreSQL webapp database

(Flow B) 

In this case, Zapier would not be responsible for communication between the two Postgres

databases.

 

Unfortunately, we haven’t able to get 100% clarification on this issue from support or in the documentation.  We still have these questions:

  1. Which is recommended, Flow A or Flow B?  Or in other words, should Zapier only talk to an intermediary database, or can it talk directly to a production database?
  2. If Flow B is recommended, what are the risks of talking directly to the production database?
  3. Is there any existing documentation that further explains why an intermediate database is necessary?
  4. If Flow B is recommended, is Postgres replication considered an acceptable out-of-band process?

Thank you,

 

Alan

Hi @alaser-te!

 

I’m not an expert on PostgreSQL but my understanding is that the purpose of the intermediate database is a layer of safety, so you’re not directly exposing your database to Zapier. 

In this case, Zapier would not be responsible for communication between the two Postgres databases.

That’s exactly it - you have a separate database that acts as a go-between so that Zapier doesn’t have direct access to your production database. 

I don’t know enough to comment on why this is the best solution, perhaps someone else here will have some more insight. If not it might be worth asking PostgreSQL if they can explain the risk. 

 

I hope that helps!

Terms & Conditions