Integrations FAQ
Integration architecture, connection methods, security measures, scheduling options, performance considerations, and specific integration details.
Last updated
Was this helpful?
Integration architecture, connection methods, security measures, scheduling options, performance considerations, and specific integration details.
Last updated
Was this helpful?
Was this helpful?
Veza connects to metadata sources (such as Identity Providers, Cloud Providers, SaaS Applications, and Data Lakes) through integrations managed on the Integrations page. Each integration periodically synchronizes to discover new data sources and extract current authorization metadata.
Veza integrations connect via read-only APIs to gather the necessary metadata information to create that integration’s access graph. Veza leverages the best-practice connection methodologies for each connector we build. Veza also generally supports additional connection methods, when another method defined by the target is the preferred method for the customer.
Identity Metadata: User attributes and entitlements, including role assignments and group memberships.
Employee Attributes: Unique identifiers (e.g., Employee Number, Unique ID), employment details (e.g., job title, employment status), and organizational structures (e.g., department, cost center).
Application Metadata: Local users, groups, roles, permissions, and metadata related to resources and data objects that identities can access.
Refer to individual integration guides for detailed information on supported entities and attributes.
Deploying an Insight Point enables secure discovery of data sources that prohibit external connections from outside your corporate network. Typically deployed as a Docker container, Kubernetes service, or VM OVA, the Insight Point runs within your network to query internal-only data sources for authorization metadata and push that information to the Veza graph.
Veza normalizes the status of users from various Identity Providers (IDPs) into a single Is Active boolean property. This provides a consistent attribute for filtering and searching across all IDPs in the Veza Access Graph.
The logic for determining the Is Active status is based on the user's status in the source IDP. While the specific logic varies between IDPs, the general principle is to mark a user as inactive if their account is disabled, suspended, or otherwise in a state that prevents them from authenticating.
For detailed information on how the Is Active status is determined for each IDP, please refer to the "User Active Status" section in the respective integration documentation:
In addition to the Is Active property, Veza may also store the raw status from the IDP in a dedicated attribute (e.g., User Account Control for Active Directory, Status for Okta) to allow for more granular filtering and analysis.
An Insight Point is a lightweight, static binary designed for secure metadata extraction within customer networks. It is packaged in various formats such as Docker container and OVA image, enabling integration of internal resources to Veza without direct/external exposure. The Insight Point performs local metadata collection and securely transmits the data to the customer’s Veza instance.
Insight Points operate on a pull-based architecture:
The Insight Point will securely connect to the customer’s configured Veza instance to retrieve extraction tasks.
The Insight Point will take the response and perform the requested extraction work locally.
After extraction, the Insight Point transmits the data back to the configured Veza instance.
No. All communication is strictly unidirectional with all connections initiated from the Insight Point. Veza cannot initiate inbound connections to the Insight Point.
Yes. Veza’s Insight Point supports working through corporate firewall configurations, network proxy requirements, and standard enterprise network security controls.
Veza can schedule best-effort custom extraction intervals for different integrations. Each integration has a default extraction interval. Most integrations default to hourly extractions.
Administrators can customize this interval for each integration (1 hour to 30 days) on the System Settings page to optimize cost, performance, and data freshness. Some integrations, such as SharePoint and Snowflake, support activity-based extraction, enabling updates only when changes are detected.
Veza minimizes impact on business-critical systems with rate-limited API calls, optimized queries, and configurable extraction intervals. For supported integrations, administrators can enable activity-based extractions that only trigger when changes are detected, and set limits on the specific services, entities, and attributes gathered by Veza.
Each integration handles extraction errors based on application-specific best practices, using automatic retry logic for recoverable issues. Non-recoverable errors (like missing permissions or service unavailability) fail the extraction and trigger a retry at the next scheduled interval. Administrators can monitor all extraction statuses and errors through the integration Details view and the Events page. Veza also supports exporting these events to external systems.
Unfinished jobs are eventually interrupted and retried at the next extraction interval to prevent pipeline delays. Large extractions can take some time to complete, and are allowed to run for extended periods.
Integration discrepancies can occur when entity counts or attributes don't match between Veza and the source system. Use this approach to identify and resolve common issues:
When Veza displays fewer entities than the source system:
Data synchronization delay – New data may not have synced to Veza yet. Check the integration's last successful extraction time on the integration Details page. Manually trigger an extraction or wait for the next scheduled sync.
Authentication issues – Verify that integration credentials are valid and haven't expired. Review any authentication errors in the Events page.
Scope limitations – Confirm that Veza has been authorized to access all required data sources and organizational units within the integration scope.
Extraction failures – Check for partial extraction failures that may have prevented complete data collection. See individual integration guides for platform-specific troubleshooting steps.
When entity attributes don't match between systems:
Data synchronization delay – New data may not have synced to Veza yet. Check the integration's last successful extraction time on the integration Details page. Manually trigger an extraction or wait for the next scheduled sync.
Integration sync failures – Review integration details for any missed extractions due to missing permissions or connection issues, which could result in stale data in Veza.
Additional troubleshooting resources:
For persistent issues or complex troubleshooting scenarios, contact Veza technical support or your customer success manager for specialized assistance.
Veza protects integration data with multiple security layers. See the Security FAQ for detailed information about Veza's security and encryption practices.
All communication uses TLS 1.2+ and AES-256 encryption.
Integration secrets (such as OAuth credentials and API keys) are securely stored, with the option to manage using external vaults.
Access to integration secrets is strictly limited to authorized Veza extraction services.
To integrate with Microsoft Entra ID, Veza connects through an Azure App Registration with read-only permissions to the Microsoft Graph API. It retrieves metadata about:
Entra ID roles and role assignments
Groups and group memberships
Users and their attributes
Service principals and their assigned roles
Optional permissions can be added for services like SharePoint, Intune, and Key Vault, depending on the resources Veza will access. For detailed configuration steps, see the Microsoft Azure Integration Guide.
The Veza integration for Snowflake data lake discovery uses a local user configured with a role that grants access to metadata on:
Users and their attributes
Roles and role hierarchies
Resources (databases, schemas, tables, and views)
Permissions and access control policies
The user must have usage privileges on a virtual warehouse (e.g. compute_wh). You can create an alternative system database with minimal required views for greater access control. Key pair authentication is available as an alternative to passwords. Secure communication between Veza and Snowflake is typically managed using an Insight Point. For detailed implementation steps, see the Snowflake Integration Guide.
To integrate with Salesforce (SFDC), Veza connects via a Salesforce Connected App configured with API permissions to retrieve:
User profiles and permissions
Groups and their memberships
Permission sets and assignments
Data objects and access controls
Sharing rules and account shares
The Connected App uses an X.509 certificate for JWT-based OAuth 2.0 authentication. Veza analyzes permissions, group memberships, and account shares to provide insights and generate effective permissions. Integration configurations support object-level filters and license-based restrictions on the metadata Veza collects. For step-by-step setup instructions, see the Salesforce Integration Guide.