Cookie settings

We use cookies

Necessary cookies keep the website working and store your choice. With your consent, we can also use functional cookies to remember the theme preference and analytics cookies to measure website usage.

You can accept optional cookies all at once, reject them, or choose individual categories. You can change your consent later; details are available in the Cookies Policy.

LaraDep Documentation

You are reading Managed mode

Roles, security and access control in managed mode

How to set role model, access control and decision points in managed mode: stability, control and audit trail.

Access and access governance in managed mode

Managed mode is often chosen for speed, but it still requires strict governance. Without clear roles and permission model, the same process can become risky and non-auditable.

Purpose and assumptions

  • Purpose: establish predictable ownership for every change: who requested, who approved, who executed, who verifies.
  • Prerequisites: an operational workspace model is in place and team members understand run history semantics.
  • What you need: role matrix, change categories, and communication channel for incidents and windows.

Role model

  1. Change owner — proposes and prepares the change scope.
  2. Approver — confirms readiness and grants deployment permission for high-impact runs.
  3. Operator — executes the run through the standard flow.
  4. Reviewer — validates results and signs off outcomes in run notes.

Configuration steps

  1. Classify change categories by impact: low, medium, high.
  2. Set minimum permissions for each workspace role and avoid over-privileged defaults.
  3. Link review path so high-impact changes cannot skip approval.
  4. Define change windows and expected communication format.
  5. Require run notes before marking a deployment complete.

Validation checklist

  • Are roles applied consistently across workspaces?
  • Does each critical run include change owner and approver?
  • Are unplanned windows documented with a technical lead and impact rationale?
  • Are sensitive run notes reviewed and archived?
  • Is access revocation and periodic audit part of your routine?

Common mistakes

  • Skipping role review and relying on implicit trust.
  • One person handling request, approval and execution for all high-risk changes.
  • Postponing run notes until after rollback or after incident.
  • Allowing long-lived elevated roles without periodic review.

Next steps

Next step: Open the managed onboarding checklist before your first production change.

Subscribe to our Newsletter

Stay updated with our latest news and articles by subscribing to our newsletter.

Esc Close