FortiManager 7.6: Workspace and Workflow Modes

FortiManager has to solve a human concurrency problem as well as a configuration problem. When several administrators work in the same environment, the platform needs rules for who may edit, which objects are locked, how changes are reviewed, and when they become eligible for installation. Workspace and workflow modes provide those controls.

The current Fortinet NSE path now places FortiManager 7.6 Administrator in NSE 6. The older FCP_FMG_AD-7.6 identifier remains useful only as ExamSnap’s established target. The technical focus here is current FortiManager 7.6 change governance.

Choosing a mode is not about enabling the most restrictive option. It is about matching team size, change risk, administrative overlap, and approval requirements while avoiding lock contention and unclear ownership.

Normal mode assumes low administrative contention

In a simpler operating model, administrators may work without explicit workspace locks. This reduces friction and is practical when a small trusted team coordinates changes closely.

The trade-off is that concurrent editing can be harder to control. Teams need discipline around ownership and timing because the platform is not using locking to prevent overlapping changes in the same way workspace mode can.

Normal mode therefore works best when change volume and administrator concurrency are low enough that process can reliably manage conflicts.

Workspace mode makes editing ownership explicit

Workspace mode introduces locking so an administrator can reserve a configuration scope before changing it. A lock signals that another session owns the edit context, reducing accidental collision.

Locks improve safety but create operational cost. An abandoned session or forgotten lock can block urgent work. Teams need procedures for identifying the owner, validating whether the work is still active, and releasing locks safely.

Locking should protect meaningful boundaries rather than become a substitute for communication.

Per-ADOM locking scales concurrency

Per-ADOM workspace behavior allows administrators to work in separate administrative domains without locking the entire FortiManager configuration. This can increase throughput in organizations where teams manage independent environments.

The benefit depends on ADOM design. If responsibilities are poorly separated or shared dependencies are frequent, per-ADOM locking may not remove enough contention. Good workspace design therefore begins with good administrative boundaries.

Teams should understand what is locked and what remains available before assuming two changes are independent.

Workflow mode adds approval to the change lifecycle

Workflow mode extends change control beyond editing locks by introducing formal review and approval states. An administrator can prepare a change while another authorized role evaluates whether it should proceed.

Approval creates separation of duties and an auditable decision point, but it also adds lead time. Organizations should use it where risk or governance justifies the delay rather than applying complex approval to every low-impact change.

Reviewers need enough context to make a decision: intended outcome, affected devices or policies, risk, testing evidence, and rollback approach.

Sessions define the unit of work

A workspace or workflow session helps group changes into a coherent unit. That makes it easier to understand what an administrator intended and what should be reviewed together.

Sessions should be scoped carefully. Very large sessions mix unrelated changes and make review difficult; very small sessions create excessive administrative overhead. A useful unit corresponds to one change objective or tightly related set of changes.

Clear session naming and notes improve handoff when another person must review or complete the work.

Locks can become an operational incident

A lock that protects concurrent editing can also delay an urgent change when the owner is unavailable. Teams should know how to determine lock ownership, whether the session contains unsaved work, and what governance is required before forcing release.

Force-unlocking should not be routine. Removing another administrator’s lock without understanding the session can cause work loss or conflicting edits.

Escalation paths are therefore part of workspace-mode design, especially for environments that require around-the-clock operations.

Approval does not replace technical validation

A reviewer can approve intent while still missing a configuration error. Workflow should therefore pair human approval with technical checks: target verification, configuration diff, policy validation, install preview, and post-install verification.

Likewise, a technically valid change may still be inappropriate from a governance perspective. The approval process should consider both correctness and authorization.

Strong change control combines machine evidence with human responsibility rather than assuming one can replace the other.

Auditability improves when ownership is visible

Workspace and workflow modes create useful evidence about who edited, who approved, and which session produced a change. That history helps during incident review and compliance assessment.

Audit evidence is strongest when it connects to an external change record or business reason. Platform logs can show who clicked approve; the organization still needs to know why the change was needed.

Fortinet management becomes easier to govern when administrative permissions, session ownership, and approval roles are designed as one system.

Choose the simplest mode that controls the real risk

A single-admin lab does not need the same workflow as a global security team with many ADOM owners. More control is useful only when the organization can operate it consistently.

Normal mode minimizes friction, workspace mode manages concurrent editing, and workflow approval supports formal separation of duties. The choice should reflect how often administrators collide, how sensitive changes are, and what evidence governance requires.

Candidates should be able to reason from the team and risk scenario to the mode, then explain the new failure modes that control introduces—especially lock contention, stale sessions, approval delay, and unclear emergency procedures.

Team topology should influence mode selection. If each ADOM has a stable owner, per-ADOM workspace locking may provide enough isolation. If many administrators regularly collaborate on the same policy set, teams may need tighter session conventions and stronger review. If regulatory separation of duties applies, formal workflow approval can be more important than editing concurrency.

Emergency changes require a designed exception path. An incident may justify bypassing a normal approval delay, but the organization should define who can authorize that path, how the change is recorded, and how it is reviewed afterward. Otherwise ’emergency’ becomes a permanent way around governance.

Workspace settings also affect automation and API workflows. Automated jobs should not unexpectedly collide with human-held locks or workflow sessions. Integrations need to detect lock state, fail clearly, and avoid forcing changes when the management database is not in the expected state.

Operational dashboards or reports should surface aging sessions and locks. A session that remains open for days may indicate abandoned work, a blocked deployment, or unclear ownership. Proactive cleanup is safer than discovering the issue during an urgent change.

Approval quality depends on readable change information. Reviewers should see meaningful diffs and understand which devices or policies are affected. If a session contains hundreds of unrelated changes, approval becomes ceremonial because no reviewer can assess the risk reliably.

Mode changes themselves should be governed. Switching an active FortiManager environment into or out of workspace/workflow operation can alter how administrators work and how pending changes are handled. Teams should plan the transition, communicate expectations, and verify that automation, permissions, and emergency procedures still function.

Session hygiene is a practical security control. Administrators should close or submit completed sessions rather than leaving them open as informal storage. Old sessions can confuse ownership and make it harder to know which configuration reflects current intent.

Workflow approvers should be independent enough to challenge the change. If the same individual always authors and rubber-stamps work through a shared account or delegated shortcut, workflow mode adds ceremony rather than separation of duties. Roles and authentication should preserve individual accountability.

Organizations should decide how rejections are handled. A rejected session needs clear feedback and a controlled path back to editing; creating a second session without closing the first can fragment the change history. Review comments should explain which risk or requirement was not satisfied.

Change dependencies also matter. Two sessions may be individually valid but conflict when both alter shared objects or assumptions. Teams should sequence dependent work and avoid approving a later session that relies on an earlier change which has not yet been installed.

Training is essential when switching modes. Administrators accustomed to immediate edits may misunderstand locks, sessions, or approval states and assume the platform is malfunctioning. A short operating standard describing lock ownership, session lifecycle, emergency changes, and approval expectations prevents many avoidable incidents.

Periodic review should test whether the chosen mode still matches the organization. Team size, compliance requirements, automation volume, and ADOM structure change over time. Governance that was efficient for three administrators may be too weak—or unnecessarily complex—for a much larger operations group.

Metrics can show whether a governance mode is helping. Lock duration, abandoned sessions, approval latency, rejected changes, emergency bypasses, and install failures reveal whether the process is proportionate or creating workarounds.

A well-chosen mode should make responsibility clearer without making safe change impossible. The goal is controlled collaboration: people know who owns the work, what is being reviewed, when a change is approved, and how to recover when the workflow itself becomes blocked.

That clarity is the real purpose of workspace governance: make every administrative change attributable, reviewable, and recoverable before it reaches managed firewalls.