Choosing the right integration strategy for your organization

Documentation Index

Fetch the complete documentation index at: https://parabola.io/docs/llms.txt

Use this file to discover all available pages before exploring further.

When your team connects Parabola to third-party systems like NetSuite, Sharepoint, Salesforce, or your data warehouse, you have a choice about how those connections are authenticated. The right strategy depends on how sensitive the data is, how broadly it needs to be shared, and how much ongoing maintenance your IT team is willing to take on. This guide is geared toward IT admins, security teams, and ops leaders at larger organizations who are standardizing how Parabola connects to their stack. If you’re a single builder getting started, the default behavior - connecting your own account and sharing as needed - is usually all you need. Come back here when you’re ready to scale access across a team.

​

The three authentication approaches

Parabola supports three patterns for authenticating to third-party integrations. You can use any combination of them across your account.

​

1. Individual user-level authentication

Each user connects their own credentials to the third-party service. The integration inherits whatever permissions that user has in the source system. Pros:

• Users can only access data they’re already permitted to view in the source system.
• Authentication details stay private to the connecting user.
• Activity is most traceable back to a specific individual, which helps with audit trails.

Trade-offs:

• Can inhibit collaboration on Parabola, since a flow that depends on one person’s connection may break if that person leaves or loses access.
• Multiple users may end up connecting the same service redundantly.

When to use it:

• Highly sensitive systems where source-system permissions should govern what each user sees (for example, HR data, finance systems with row-level controls).
• Regulated environments where individual attribution matters for audit.

​

2. Parabola service account authentication

A single dedicated service account - typically owned by IT or a system administrator - is connected to the third-party integration and shared with the relevant Parabola users. Pros:

• All Parabola users authenticate to the third-party integration through one shared credential.
• Easy to manage: one account to provision, monitor, and reauthorize.
• Connections don’t break when individual users leave the company.

Trade-offs:

• Results in a “one scope fits all” situation - every user accessing the integration sees the same data, scoped to whatever permissions the service account holds.
• Less granular attribution, since actions on the integration trace back to the shared account rather than the individual user. Remember, Parabola will still have user attribution on actions made on the flow like editing and running.

When to use it:

• Standard operational data (ERP exports, shipping data, sales channel data) where the whole ops team needs consistent access.
• High-volume or scheduled flows where credential continuity matters more than individual attribution.

​

3. Share with Parabola Tables

Instead of giving end users direct credentials to the third-party system, an admin (or a designated builder) pulls data from an integration into Parabola Tables and shares only the resulting table with downstream users. The integration credential lives with the upstream flow; consumers work off the curated table. Pros:

• Source credentials stay completely private - only the admin who built the upstream flow ever touches them.
• Users get controlled, auditable access to exactly the data they’re approved to use.
• You can shape, filter, and redact data before it’s exposed to consumers.

Trade-offs:

• Highest ongoing maintenance load for the IT or data team, since reauthentication and source-data freshness fall on the admins who own the upstream flows.
• Adds a layer of indirection - consumers can’t pull live data themselves; they depend on the upstream flow running.

When to use it:

• Sensitive systems where you want a hard separation between credentials/direct integration access and consumers (financial systems, customer PII, restricted data sets).
• Data that needs to be pre-processed, filtered, or joined before downstream teams should see it.
• Situations where you want one source of truth that multiple flows can read from.

​

Choosing the right approach

A quick comparison to help you decide:

​

Mix and match across your account

You don’t have to pick just one approach. Most larger organizations mix all three based on how sensitive each integration is:

• Use individual user authentication for tools where the source system’s permissions already do the right thing.
• Use a service account for the bulk of operational integrations where consistency and continuity matter most.
• Use Parabola Tables as a wrapper for the most sensitive sources, exposing only what downstream teams need.