Appearance
Users & Access
Manage who can access your YuzeData organization and what they can do. This includes users (people), groups (collections of users), and API clients (external systems).
Users
Users represent individual accounts that can access your YuzeData organization. Each user has a login identity, assigned roles that determine their permissions, and can belong to one or more groups.
How Users Are Created
Users authenticate through your organization's configured identity provider (IdP) (e.g., Azure AD, Okta). When a user logs in via SSO for the first time, their account is automatically created in YuzeData.
User provisioning is typically managed through your corporate identity provider.
Info
For child customers, users can only be created from the parent tenant. Child customers cannot create users directly.
User Roles
Roles determine what a user can do in YuzeData. Assign roles directly to users or through group membership.
Common roles include:
- Administrator: Full access to all features
- Integration Engineer: Access to workflows, connectors, and data
- Viewer: Read-only access to data and reports
User Audit
The Audit tab on a user's page shows who changed the user, what they changed, and when. Go to Organization → Users, open a user, and select Audit. Changes are grouped by day, with the newest first. Each entry says who made the change and where it came from, such as the web app or the assistant. Expand an entry to see each changed field with its value before and after: first and last name, email, job title, status, roles, and identity providers.
When a YuzeData support engineer temporarily raises their own access, the entry on their user shows the reason and when the access ends.
Users that existed before change tracking was switched on start with a Change tracking started entry. It records the user as they were at that moment. Earlier changes, and who made them, are not known.
Info
Changes to group membership and sign-ins are not part of a user's audit.
Groups
Groups organize users and manage permissions collectively. Instead of assigning roles to each user individually, assign roles to a group and add users as members. All group members automatically inherit the group's roles.
Why Use Groups?
- Easier onboarding: Add new users to appropriate groups instead of configuring individual permissions
- Consistent access: All team members have the same permissions
- Centralized updates: Change a group's roles to update permissions for all members at once
- Clear organization: Groups reflect your team structure (e.g., "Data Engineers", "Analysts")
API Clients
API Clients provide authentication credentials for external systems to integrate with YuzeData. When an external system needs to call YuzeData APIs or send data to HTTP API connectors, it authenticates using an API client.
When to Use API Clients
Create an API client when:
- An external system needs to push data to YuzeData via webhooks
- A third-party application needs to call YuzeData APIs
- You're building a custom integration that runs outside YuzeData
Authentication Strategies
OAuth2 - Standard client credentials flow:
- Client ID: Public identifier for the client
- Client Secret: Private key for authentication
- When creating a secret, choose an expiration period (1 month, 3 months, 6 months, 1 year, or never)
- Expired secrets cannot be used to obtain access tokens
- Default expiration is 3 months for security best practices
Security Best Practice
Avoid using "never" expiration for production secrets. Regular rotation of credentials reduces security risks if a secret is compromised.
- External systems request access tokens using these credentials
- Tokens are used in API requests via the
Authorizationheader
Webhook - Signature-based authentication:
- Signature Algorithm: Method used to sign requests (e.g., HMAC-SHA256)
- Signature Header: HTTP header containing the signature
- Secret: Shared key for signature verification
- YuzeData validates incoming requests by verifying the signature
API Client Access Control
API clients can be granted access to specific resources:
- Connector Access: Grant access to specific HTTP API connectors
- Master Data Access: Control read/write access to master data
- Scopes: Define operations the client can perform (Read, Write)
