FortiManager can allow administrators to edit without locking, or it can require explicit locks before changes are made. Workspace mode exists to solve a coordination problem: several administrators may be working in the same ADOM at the same time, and central management becomes unsafe if they unknowingly modify the same policy, object, or device state.<\/p>\n
For the NSE 6 FortiManager 7.6 Administrator<\/a>, workspace mode is not just a GUI feature. It changes the editing workflow, determines what must be locked, and affects how teams handle concurrent administration, abandoned sessions, emergency access, and change ownership.<\/p>\n Fortinet documents the disabled state as the default operating model in which administrators can make changes without first locking an ADOM, device, or policy package. This is simple for small teams, but two administrators can work on related configuration at the same time and create conflicts or overwrite expectations.<\/p>\n The risk is not limited to two people editing the same firewall rule. One administrator may change an address object while another changes policies that use it. A third may install the package before either change has been reviewed as a combined set. Centralization makes collaboration easier, but it also makes coordination failures broader.<\/p>\n Workspace mode adds an explicit ownership signal so that \u201cwho is changing this?\u201d is represented by the system rather than by chat messages or assumptions.<\/p>\n When workspace mode is enabled, FortiManager makes Device Manager and Policy & Objects read-only until the administrator acquires an appropriate lock. Depending on the scope, the administrator can lock an entire ADOM, an individual device, or a policy package.<\/p>\n This creates a clear sequence: acquire ownership, make the change, save or install as required, and release the lock. Other administrators can see that the resource is in use and avoid making conflicting edits. The lock is therefore a coordination control, not a security policy that replaces administrator permissions.<\/p>\n Workspace mode can be enabled across all ADOMs or configured per ADOM. Fortinet also notes that changing workspace settings ends the current session and requires a new login, which is operationally important during maintenance planning.<\/p>\n An ADOM lock is broad. It is appropriate when the change spans multiple devices and policy packages, when new devices or packages must be created, or when the operation cannot be safely divided. Broad locks reduce concurrency, so using them for every small change defeats part of the value of multi-administrator management.<\/p>\n Device and policy-package locks allow different administrators to work in the same ADOM at the same time when their work does not overlap. This can improve throughput in large operations teams, but only if object ownership and shared dependencies are understood.<\/p>\n Some actions still require an ADOM-level lock. Fortinet documents, for example, that the entire ADOM must be locked to create a script, even though a script may be run directly against a device when only the device is locked. The correct lock scope depends on the operation.<\/p>\n Fortinet warns that individual devices cannot be locked when ADOMs use advanced device mode. Advanced mode can distribute VDOMs from one FortiGate across different ADOMs, which complicates the ownership model and makes device-level locking less straightforward.<\/p>\n This is another reason multi-tenant architecture and change-control architecture should be planned together. A design that chooses advanced ADOM mode for VDOM placement may also change how administrators can isolate concurrent work.<\/p>\n Before enabling advanced mode, verify not only that the tenant mapping requires it, but also that the operations team understands the resulting workspace behavior. Flexibility at one layer can remove simplicity at another.<\/p>\n Locks are useful only when teams release them. A disconnected administrator, forgotten session, or unfinished change can leave another operator unable to proceed. FortiManager allows broader lock ownership to be broken by disconnecting the administrator that holds a conflicting lock, but doing so should be a controlled action.<\/p>\n Before breaking a lock, determine whether uninstalled or unsaved work exists and why the original administrator is unavailable. An emergency change may justify intervention, but silently taking over a lock can cause exactly the loss of work workspace mode was meant to prevent.<\/p>\n Define an escalation rule: who may break locks, how the original change is preserved, how the event is documented, and how affected administrators are notified. Technical locking works best when paired with social change-control rules.<\/p>\n A lock prevents concurrent editing; it does not automatically provide peer review, business approval, or separation of duties. Organizations that require formal approval still need a workflow around the FortiManager edit-and-install process.<\/p>\n For example, an engineer can lock a package, prepare a change, and generate an Install Preview. A second role can review the preview and maintenance ticket before the install occurs. Workspace mode protects the editor’s work while the external or built-in approval process governs whether the change should be deployed.<\/p>\n This distinction matters because technical exclusivity and governance answer different questions. \u201cCan someone else edit this at the same time?\u201d is not the same as \u201chas this change been approved?\u201d<\/p>\n A practical operating rhythm is to announce the intended scope, acquire the smallest useful lock, make changes, review the diff, install or save, verify the target, and then release the lock promptly. Change comments should identify the reason and owner so that later revision history tells a coherent story.<\/p>\nWithout workspace mode, concurrency is permissive<\/h2>\n
Workspace mode makes managed areas read-only until locked<\/h2>\n
Lock the smallest scope that safely contains the change<\/h2>\n
Advanced ADOM device mode changes lock behavior<\/h2>\n
Locks need an abandonment and escalation procedure<\/h2>\n
Workspace mode is not the same as workflow approval<\/h2>\n
A safe multi-administrator rhythm is predictable<\/h2>\n