In general, Opal supports both centralized and de-centralized approval structures. However, these don't have to be mutually exclusive, and you can also mix and match depending on the resource.
Let's go over what centralized and de-centralized approaches might look like.
Centralized approval workflows involve routing all requests to one central team. Although this is easer to set up, it is much harder to scale over time. Having one central owner means that they might not have the necessary context to approve requests and cannot keep up with the volume of requests.
For some resources, it might make sense to have a centralized approval workflow. To achieve this, you can leverage the Connection owner feature in Opal. Every resource associated with a connection will automatically assume the Connection owner as the Resource owner. However, the owning team of the resource can be modified manually by the Opal admin (as in the de-centralized model below).
Decentralized approval workflows involve routing different requests to the relevant owning teams. This approach enables access requests to scale more efficiently. Although this might have involve a bit of set up work, it is much easier to scale and maintain.
Opal admins can change the owner (and required reviewer) for any resource, group and team.
Multiple Required Reviews
For permissions that are extra sensitive, Opal supports multi-step approval workflows. This will involve approval from multiple teams. In addition, by integrating with your HRIS provider, Opal can also route access requests to managers
✏️ NOTE: Opal automatically sets owning team as the required reviewer. However, Opal admins can also add required reviewers with the pencil icon in addition to the default setting.