Service Accounts vs. User Credentials
For database connections, we strongly recommend using service accounts rather than personal user credentials:
Service accounts are dedicated accounts created specifically for programmatic access
They can be restricted to only the permissions needed for the specific use case
They're easier to audit and manage from a security perspective
If access needs to be revoked, you can do so without affecting any individual user
Permission Model
Understanding elvex's permission model is crucial for database connections:
All users of an app have the same level of access to the connected datasource
Access is not differentiated based on individual user permissions in the source system
This means if a user has access to an app, they can query any data that the service account can access
Best Practices for Multiple Use Cases
If you have different use cases requiring different levels of access:
Create separate service accounts for each use case, each with appropriate permissions
Create separate datasources in elvex using these different service accounts
Create separate apps that connect to the appropriate datasources
Manage access to these apps based on who should have access to each level of data
For example:
One datasource/app for analysts with broad access to most tables
Another datasource/app for sales reps with access only to customer data
A third datasource/app for executives with access to summary financial data
Data Processing and Security
How Data is Accessed
Database-backed datasources are accessed differently than file-based datasources
Data in database connections is not processed through elvex's RAG (Retrieval-Augmented Generation) system
The only way data is accessed is via SQL queries that elvex executes on behalf of the app
This means the data remains in your database until it's specifically queried