How to Configure FortiManager Workflows Safely

A firewall rule that looks minor can affect every user, branch, VLAN, or VPN tunnel connected to it. Adding a temporary vendor access policy, changing an SD-WAN rule, or updating a web filter profile without a controlled process can create an outage or leave unnecessary access in place. When organizations configure FortiManager workflows correctly, firewall policy changes become reviewable, traceable, and far less dependent on one administrator remembering every detail.

For small and midsize businesses, the goal is not to add bureaucracy to a simple change. It is to apply the right level of control to the systems protecting payment data, medical records, remote access, customer Wi-Fi, and core business applications. FortiManager provides the structure, but the workflow must match the organization’s devices, risk tolerance, and support model.

Start With the Right FortiManager Foundation

A workflow is only useful when FortiManager is the authoritative source for managed firewall policy. Before enabling workflow controls, confirm that FortiGate devices are properly added to the correct administrative domain, commonly called an ADOM, and that their configurations are synchronized.

An ADOM should reflect a meaningful management boundary. A business with a single firewall may only need one ADOM. A managed service environment, a multi-location organization, or a company separating production from lab systems may need separate ADOMs to prevent policy objects and administrator permissions from crossing boundaries.

Within each ADOM, organize FortiGates into device groups based on operational needs. For example, a retailer may group stores by region or firewall model, while a medical practice group may separate the main office from satellite clinics. Device grouping affects how easily teams can apply shared policy packages, objects, scripts, and configuration templates.

Policy packages deserve the same attention. A single shared policy package can reduce administrative effort when locations have similar requirements, but it can also make broad changes riskier. Separate packages are often appropriate when sites have different internet circuits, VPN requirements, network segments, or compliance obligations. The correct design depends on how similar the environments truly are, not simply how many firewalls exist.

Configure FortiManager Workflows Around Change Risk

FortiManager workspace settings determine how administrators make and release changes. Depending on the FortiManager version and ADOM configuration, workspace options may include disabled, normal, and workflow modes. Labels and available functions can vary by release, so verify the behavior in the installed version before documenting a process.

For organizations that need formal review, configure the ADOM for workflow mode. This changes the operating model: an administrator works in a session, makes changes, submits the session for approval, and waits for the designated approver before the change can be committed and installed. That separation is valuable because the person requesting a change does not automatically become the person authorizing it.

Normal workspace mode can be a reasonable choice for a small IT team handling low-risk, routine administration. It still provides session-based change control, but it may not enforce a formal approval sequence. Workflow mode is more appropriate when changes affect regulated systems, shared production environments, multiple sites, or a managed service relationship with defined authorization requirements.

Do not use workflow approvals as a substitute for technical review. An approver should understand the reason for the requested access, the systems involved, the expected duration, and the potential effect on segmentation. Approving a rule because the request has a ticket number is not enough.

Build roles that reflect actual responsibilities

Role-based access control should support the workflow rather than undermine it. Assign administrators only the permissions required for their responsibilities. A help desk technician may need visibility into device status and VPN users without the ability to alter firewall policy. A network engineer may create and submit policy changes, while a security lead, internal IT manager, or designated service provider approver reviews high-impact requests.

Avoid shared administrator accounts. Individual accounts improve accountability, simplify offboarding, and make audit records meaningful. If emergency access is necessary, document who can use it, when it is permitted, and how changes made under emergency access are reviewed afterward.

Approval rules should also recognize that not every change carries equal risk. A change to an unused address object is different from an inbound virtual IP for a public-facing application. A practical process can classify changes as routine, standard, high risk, or emergency. The workflow can then require different reviewers and maintenance windows based on that classification.

Make Every Change Session Specific

A FortiManager workflow becomes easier to manage when each session has a clear business purpose. Name sessions consistently, such as `CHG-1042 - Add vendor VPN access - Accounting`. The name should let an approver and future administrator understand the scope without opening every policy object.

Inside the session, limit edits to the requested work. Combining a scheduled firewall rule update with unrelated policy cleanup makes review harder and rollback less certain. If a rule must be changed, document the source, destination, service, schedule, NAT behavior, security profiles, and business owner. For temporary access, include an expiration date in the request and establish a follow-up task to remove it.

Before submission, use FortiManager’s revision history and policy comparison capabilities to review the proposed delta. Look for unintended object changes, policy order issues, duplicate rules, overly broad services such as ALL, and a source or destination that includes more networks than required. This is where a large percentage of preventable firewall errors are caught.

Validate Policy Before Installation

Approval is not the final technical checkpoint. A policy can be approved and still fail because it references an unresolved object, conflicts with a local interface design, or is installed to the wrong device group. Review the target scope before installation, especially when a package applies to multiple locations.

Install previews and policy checks should be part of the release process. Confirm that the intended FortiGates are online and manageable, that the policy package assignment is correct, and that the installation window will not interrupt active business operations. For changes involving routing, VPNs, SD-WAN, certificates, or central NAT, a peer review is often justified even when the policy workflow does not require one.

A controlled change also includes a validation plan. Define what success looks like before installation. That may be a successful VPN connection from an approved user group, reachability to a published application from an allowed source, a successful card-processing test on a segmented payment VLAN, or confirmation that a branch can fail over to its secondary internet circuit.

Where possible, test changes first on a representative firewall or during a maintenance window. A lab is useful, but it may not reveal differences in ISP handoffs, dynamic routing, local switches, wireless networks, or legacy application behavior. Production validation should be deliberate and limited, not improvised during a busy workday.

Plan Rollback Before the Install Button

Every workflow should have a rollback path. FortiManager configuration revisions provide a practical foundation because they preserve known states before changes are installed. Capture or verify a clean revision before a major policy, VPN, routing, firmware, or template update. If the change causes an unexpected issue, the team can identify the last known-good configuration and restore the affected scope with less guesswork.

Rollback is not always as simple as reinstalling an earlier package. A change may interact with local device settings, dynamic objects, certificates, external authentication, or another change made after the original revision. For that reason, the rollback plan should state who will make the decision, what condition triggers it, and what business impact is acceptable while restoration occurs.

For critical systems, keep a communications plan alongside the technical plan. The office manager, operations lead, application owner, and IT contact should know whether a change is expected to affect remote users, point-of-sale terminals, guest Wi-Fi, or access to cloud services. Clear communication shortens incident response if the result differs from expectations.

Keep Workflow Records Useful After Approval

The value of FortiManager workflows extends beyond the day of the change. Session history, approval records, device revisions, and installation logs help teams answer practical questions months later: Why was this rule created? Who approved this inbound access? Which package was installed at the branch before the VPN issue began?

Review these records during regular firewall policy hygiene. Remove expired rules, consolidate duplicate objects, confirm that disabled rules are not masking unresolved work, and verify that privileged administrator accounts remain appropriate. Businesses working toward PCI DSS, NIST-aligned controls, CIS benchmarks, or customer security requirements benefit from having evidence that changes were requested, reviewed, installed, and validated.

Kamanel Consulting typically treats FortiManager workflow design as part of a larger operational discipline that includes configuration backups, firmware planning, policy reviews, and ongoing support. The strongest workflow is the one staff can follow consistently during both planned maintenance and time-sensitive troubleshooting.

A well-configured FortiManager workflow should make a legitimate change easier to approve and an unsafe change harder to release. Start with one ADOM, one policy package, and a clear approval path if necessary, then refine the process as the environment grows. That approach protects day-to-day operations without turning firewall management into a bottleneck.