Video overview
Two layers of permissions
Access in Parabola operates at two distinct levels, and it’s important to understand both:- Flow-level permissions — who can see and edit a flow
- Integration-level permissions — who can use the credentials that connect a flow to an external system
Flow-level permissions
By default, flows are private — only the person who created them can see or edit them. Visibility opens up in layers:| Level | Who has access |
|---|---|
| Private | Flow owner only (default for all new flows) |
| Shared | Specific team members the owner grants view or edit access |
| Team flows | Anyone in the organization gets viewer access; the owner can optionally grant everyone editor access |
| Content admin | Admins with content permissions have edit access to all flows in the organization |
Moving a flow into the Team flows space automatically grants your entire organization viewer access. To give a specific person edit access instead, use the sharing modal within the flow.
Integration-level permissions
Integration credentials are completely private by default — only the person who created them can see or use them. This applies even to org admins. You can share credentials with specific teammates at two levels:| Permission | What it allows |
|---|---|
| Use | The teammate can use this credential in their flows, but cannot view or modify it |
| Edit | The teammate can modify the credential and re-authenticate on behalf of the team |
Three approaches to integration authentication
There’s no single right answer here — and you can mix approaches within your team, applying different methods based on how sensitive or restricted a given integration is.- Individual user authentication
- Service account authentication
- IT-managed access via Parabola Tables
What it is: Each user connects their own personal credentials for third-party services (e.g. their own Google Drive account).Best for: Teams where traceability matters — you need to know exactly whose credentials were used when a flow ran.Trade-offs: Most traceable, but creates a fragility risk. If a flow relies on one person’s credentials and they leave, the flow breaks until someone reconnects it.How to set it up:
Which approach should you use?
If you’re not sure where to start:- Default to service account authentication for most integrations — it’s the most practical for a team environment and easiest to maintain over time
- Use individual authentication when you need a clear audit trail and traceability to specific people matters
- Use IT-managed Parabola Tables when your data governance policy requires that users have no direct access to the source integration
Security & compliance basics
Your IT or InfoSec team will eventually ask about Parabola’s security posture. Here’s what you need to know: Platform security:- Parabola is SOC 2 compliant and conducts annual third-party penetration tests
- Flow data stays in memory during execution and is never written to disk — it’s deleted after 14 days or when the flow next runs
- Integration credentials are stored separately with 256-bit encryption
- Parabola support can only access your flows read-only, and only with your permission
- AI steps in Parabola are powered by the best and most recent models under enterprise agreements with DPAs
- AI providers will not use prompt contents from Parabola AI steps as training data
- Only data from the specific columns you select is sent to AI providers (with the exception of the Experiment with AI step, which uses the full dataset)
- Parabola is data-neutral and data-agnostic — the platform processes what you configure it to process, without inspecting or monitoring the data itself
- You are responsible for ensuring you have permission to process the data you bring into Parabola
What’s next
In the final full lesson, we’ll cover the operational side of admin work: adding and removing users, organizing flows into folders, and keeping everything running smoothly over time.Building challenge
Review the integration credentials currently connected to your team’s account.