.png)
If you have ever worked inside a growing team, you have likely experienced the tension between collaboration and control. As teams expand, responsibilities diversify, and suddenly the same dashboard is being used by developers, data analysts, product managers, and compliance stakeholders. Everyone needs access, but not everyone needs the same access.
What initially feels efficient can quickly become risky. A developer working on a webhook update might accidentally modify a production configuration. A data analyst may require production data for reporting, but should not be editing integration settings. An admin might hesitate to grant broader permissions simply because there is no structured way to limit them.
In digital health, this challenge carries additional weight. Production environments contain live user data, active integrations, and sensitive health information. A configuration change is not just a technical adjustment; it can affect data pipelines, reporting accuracy, and even user-facing functionality. As organizations scale, relying on shared full-access permissions is no longer sustainable.
That is precisely why we introduced Role-Based Access Control on the Thryve Dashboard.
Instead of assigning identical permissions to every dashboard user, access can now be aligned with actual responsibilities. This update was driven by feedback from larger customers managing multiple dashboard users who required different levels of control. Some team members needed full configuration authority. Others only required access to staging for testing. Data teams needed visibility into production data without the ability to modify system settings. The previous one-size-fits-all model simply did not reflect how modern digital health teams operate.
The Admin role provides full access to both staging and production environments. Admins can view and edit all service configurations, including webhooks, data sources, and data types. They can request and access health data in both staging and production, and they oversee overall dashboard management.
The first dashboard account created for a customer automatically receives the Admin role. This ensures that each organization maintains a primary portal manager with comprehensive oversight.
This role is typically assigned to infrastructure leads, senior product managers, or technical stakeholders responsible for governance and system stability.
The Developer role is designed for teams actively working on integrations and technical implementation while protecting production from unintended changes.
Developers can view and edit configurations within the staging environment. They can request and analyze staging health data, which allows for thorough testing and validation. However, they cannot edit production configurations and do not have access to production health data.
This separation enables development teams to iterate quickly without introducing risk to live systems. It creates a controlled environment where experimentation and debugging can happen safely.
The Data Analyst role recognizes that data teams require access to real-world information but should not be modifying technical settings.
Users assigned this role can view and request health data in both staging and production environments. They can also view configuration settings for transparency and understanding. However, they cannot edit any configuration parameters in either environment.
This structure allows analysts, BI teams, and researchers to work with live datasets while maintaining strict control over system configuration.
Role-Based Access applies across two primary areas: Service Configurations and Health Data Access.
Service configurations include webhooks, data sources, and data types. In the staging environment, Admins and Developers can both view and edit configurations, while Data Analysts have view-only access. In production, only Admins can edit configurations, while Developers and Data Analysts may view settings without modifying them.
Health data access follows a similarly structured approach. In staging, all three roles can request and view data. In production, Admins and Data Analysts can request and view data, while Developers do not have production data access.
This model ensures that configuration authority and data visibility are distributed according to functional need rather than convenience.
Role-Based Access supports team growth by introducing structured governance without slowing collaboration. It reduces the likelihood of accidental production changes. It limits unnecessary data exposure. It ensures that development workflows remain efficient while production environments remain protected.
Instead of relying on informal internal processes to manage risk, access control becomes embedded directly into the infrastructure.
This feature is more than a permission update. It is a step toward enterprise-ready dashboard management.
By aligning access with responsibility, organizations can:
The first dashboard account automatically receives the Admin role. Additional users can be assigned specific roles by contacting Thryve Support, ensuring controlled onboarding and structured access management.
At Thryve, we focus on building infrastructure that supports our customers' growth. As your team expands, your data workflows become more complex, and your compliance landscape evolves, your dashboard permissions should not remain static.
Role-Based Access Control ensures that collaboration does not come at the expense of stability.
If your organization is scaling its digital health operations and needs structured access control, secure production governance, and environment separation that reflects real team responsibilities, we would be happy to show you how it works.
Book a demo with Thryve and explore how our dashboard infrastructure supports secure, scalable collaboration in modern digital health environments.
For our current clients, more detailed information about Dashboard Roles can be found on our API documentation!
