Access and responsibilities

Map Lleverage access to real operational responsibility rather than granting broad access by default.

Access should follow the work people are responsible for.

A useful access review starts with the operational role, then maps that to Lleverage projects and permissions. Avoid starting from the product menu and giving people access simply because a control exists.

Questions to answer

For each group of users, establish:

• which Projects they need to enter;

• whether they only operate existing solutions or also build and change them;

• which external systems their work may reach;

• whether they should be able to configure credentials, Connections or project settings;

• which Requests they may be asked to resolve;

• what should happen when they leave the team or change role.

Use Control → Members for the current project membership and role mechanics. Organisation ownership has broader authority and should be treated accordingly.

Keep system authority separate from product access

A Lleverage user may have access to a Project while the underlying Connection carries authority in another system. Review both sides.

For example, adding a person to a Project is not the same decision as allowing that Project to send email, update an ERP record or call an external API. Connection scope and credential ownership are part of the access model too.