There's some nuance in how DailyBot manages your organization's data.
To protect everyone's right to privacy, as well as empower managers to do their best work and keep teamwork transparent, we adopted the current approach to both roles and permissions in DailyBot. Keep reading to learn more.
(Users with different roles as participants in the same check-in)
You can think of user roles as a pre-packaged set of permissions for someone in your organization. Currently, there are three org-wide roles in DailyBot, each one with its own set of expectations and responsibilities for the users that take them on.
Organization Administrator (a.k.a. "Org Admin")
This is the most powerful role in your organization, and it allows users to invite/un-invite users to the organization, add/remove teams, manage billing and privacy settings, request for the deletion of the organization, and basically anything other roles can do.
You can have as many org admins as you want and you can manage these permissions in the Organization settings, at the Members section.
This is a special role that gives users super powers to create/delete and make necessary modifications to any team in your org: they can add or remove members from any team, and they can see data related to all teams across the organization.
You can also have as many team managers as you'd like, and you can manage these permissions in the Organization settings page, at the Members section.
This is a special role for users (Members) that need to manage a specific team. As a teams manager, they can create, delete, and make modifications to their team.
You can as many team administrators per team as you need. You can manage these permissions in the Teams settings, and then opening the members window for the specific team.
This is the default role for new users that get invited or join your organization. Members can interact with DailyBot products and manage their own profile, but cannot manage teams or org-wide settings. Members can only see and operate on the teams they are members of. They can also manage their own check-ins and forms.
A permission consists of any individual configuration that a user can take on to control the behavior of a feature beyond their regular capabilities.
This is assigned by default to any new user that creates a new check-in. A check-in owner can transfer the ownership of the check-in, and it can also invite other members to be administrators if they need a certain level of independence when operating it.
This can be assigned to any user that needs to manage a specific check-in. There can be many editors in the report and the user with these permissions cannot invite other editors, nor remove these permissions from other users.
Got additional questions? Submit a new ticket.