FortiManager ADOM Design<\/a> explains why version alignment is part of management architecture, not only software maintenance.<\/p>\nRollback should be rehearsed, not assumed<\/h3>\n Teams should know how to identify the previous revision, inspect its diff, restore or re-install the intended state, and verify devices afterward.<\/p>\n
A revision is not useful if nobody knows which one is safe or how to return devices to it under pressure.<\/p>\n
Periodic drills on noncritical policy packages can expose missing permissions, install dependencies, or misunderstandings before a production emergency.<\/p>\n
Revision control is successful when every important change is reconstructable<\/h3>\n The mature FortiManager process can answer who changed what, in which ADOM\/session, why the change was made, which revision captured the before\/after state, who approved it, which devices received it, and how rollback would work.<\/p>\n
That traceability converts centralized management from a convenience tool into a disciplined production control system.<\/p>\n
Revision comments should describe intent, not repeat the ticket number. A useful note explains which service or risk the change addresses, whether it is part of an incident or planned release, and any dependency another administrator should know before using the revision as a rollback point.<\/p>\n
Workspace locking strategy should balance safety with concurrency. Locking an entire ADOM for every small edit can block unrelated teams, while disabling locks invites conflicting changes. Use the narrowest supported lock\u2014policy package, device, or ADOM\u2014consistent with the scope of the work.<\/p>\n
Workflow approval groups should be staffed for the real change schedule. A technically strong approval process becomes a bypass target if nobody is available during maintenance windows or incidents. Define emergency approvers and escalation rules without removing separation of duties completely.<\/p>\n
Install preview\/diff should be part of deployment review because FortiManager may translate central database state into device-specific CLI based on FortiOS version and mappings. Review what will actually be installed on representative devices, especially in mixed-version ADOMs.<\/p>\n
Rollback planning should include dynamic mappings and per-device values. Restoring one policy package revision may not recreate external dependencies such as routes, interfaces, certificates, or local state that changed separately. Record which elements are covered by the revision and which need another recovery mechanism.<\/p>\n
Audit history should distinguish FortiManager edits from device-side drift. If a FortiGate changes locally or becomes out of sync, the revision trail can look clean while the running device differs. Periodic retrieve\/import checks and configuration-status monitoring keep revision history connected to reality.<\/p>\n
Automation through APIs or scripts should create the same evidence as human GUI changes. Service accounts need named purpose, change references, and controlled permissions, and automated releases should still create revisions or checkpoints around significant deployments.<\/p>\n
Revision control should be included in disaster recovery. Back up FortiManager itself, understand how ADOM revisions are restored, and test whether a replacement manager can recover the intended policy history and device-management state. Revision data that exists only on one failed appliance is not a durable control.<\/p>\n
Change windows should include a freeze point. Once the approved diff is reviewed, avoid unrelated edits to shared objects or policy packages before installation. Otherwise the installed change can include content reviewers never saw even though the release references the same ticket.<\/p>\n
Revision naming should be machine- and human-friendly. Include release\/change ID, environment, and short purpose so automation and operators can locate known-good points quickly. A history full of names such as \u201crevision1\u201d or \u201cbefore change\u201d becomes nearly useless under incident pressure.<\/p>\n
Workflow metrics can identify process problems. Track abandoned locks, rejected sessions, emergency local changes, rollback frequency, failed installs, and time from edit to approval. High values can indicate either overly cumbersome governance or poor change quality that needs engineering improvement.<\/p>\n
Recovery should include object dependencies. Reverting one policy rule without reverting the shared address\/service object it depended on may not restore previous behavior. Use ADOM-level revisions for changes that span several interdependent objects instead of assuming policy-level history is always enough.<\/p>\n
Device install history should be correlated with revision history so operations can answer not only \u201cwhat was edited?\u201d but \u201cwhat actually reached this FortiGate?\u201d A revision that was never installed, or was installed only on half the target devices, should not be treated as the effective production state.<\/p>\n
Known-good revisions should be protected during major incidents and upgrades. Locking a revision against automatic cleanup ensures the recovery point remains available while teams investigate, even if many intermediate changes are created during troubleshooting.<\/p>\n
Revision control becomes trustworthy when it supports forward progress and recovery equally: administrators can collaborate without overwriting each other, reviewers can inspect meaningful diffs, installs are traceable to approved state, and rollback has been tested before it is needed.<\/p>\n
Revision history should be included in incident forensics. When policy behavior changes unexpectedly, compare the current package with the last known-good revision, review administrator sessions and install history, and correlate the change time with FortiGate traffic\/system logs. This can distinguish an intentional policy release from unauthorized or accidental configuration drift quickly.<\/p>\n
Keep every major release tied to a named revision and install record.<\/p>\n
Keep that evidence reviewable during incidents and audits.<\/p>\n
Revision history is most useful when operators can connect a configuration delta to a ticket, administrator, deployment window, and observed outcome. That context reduces recovery time because rollback decisions are based on intent and evidence rather than timestamp alone.<\/p>\n","protected":false},"excerpt":{"rendered":"
FortiManager revision control is the combination of configuration history, change isolation, comparison, approval, and install discipline that lets teams make centralized firewall changes without losing the ability to explain or reverse them. Current FortiManager supports ADOM revisions for policy packages, objects, and VPN-console settings, policy-level revision history, and workspace\/workflow modes that control how multiple administrators […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19854","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t