Automated tasks triggered

Projects in professional service firms don’t follow one path. One project type has a different task structure than another. A project in one regulatory jurisdiction requires steps that another doesn’t. A project that crosses service lines needs a task set that reflects both. Firms that manage this variety have traditionally dealt with it one of two ways: maintaining a large library of static templates, one for every possible combination, or launching a general template and then manually adjusting the tasks for each project. Neither approach scales well, and both leave room for something to be missed.

Version 4 of Feng Office introduces conditional workflows inside project templates, a way to handle that complexity without the overhead.

A conditional workflow is a set of rules built into a project template that determines which task workflows are launched based on the properties of the project being created. Instead of a template that always generates the same fixed set of tasks, a template with conditional logic looks at specific project variables and responds accordingly, triggering only the tasks that apply to that project’s actual requirements.

The conditions can be based on properties like project type, regulatory jurisdiction, or service line. When a project is created from the template and those properties are defined, the system evaluates the rules and launches the correct workflows automatically. No manual review, no post-launch adjustments, no checking whether the right tasks were included.

Consider a firm that handles two distinct but related project types that share some common tasks but diverge significantly in scope. One requires additional investigation steps, coordination with external parties, and specialized reporting, none of which apply to the simpler version of the same project.

Before Version 4, that firm either maintained two separate templates or launched one template and manually added or removed tasks depending on which type was selected. With conditional workflows, a single template handles both. When the more complex project type is selected, the additional workflows launch automatically. When the simpler type is selected, they don’t. The right task structure appears based on what the project actually requires, without anyone having to think about it.

The same logic applies to jurisdiction-based requirements, service line combinations, or any other project property your firm uses to differentiate its work.

Firms that have been managing project variety through static templates often end up with a template library that’s grown unwieldy, dozens of templates that are nearly identical but differ in one or two task sets. Conditional workflows consolidate that into fewer, smarter templates that cover more scenarios without duplicating everything around them.

When a template launches and someone has to go through the resulting task list to add what’s missing or remove what doesn’t apply, that’s a manual step that depends on the person doing it knowing exactly what should be there. Conditional logic removes that dependency. The template knows what to launch based on the project properties, and it does it automatically.

The phrase that best describes what conditional workflows provide is structured flexibility. The structure comes from the template, which defines the rules and the possible workflows. The flexibility comes from the conditions, which determine which of those workflows actually run based on the specifics of each project. For multi-disciplinary projects where the scope varies meaningfully from one engagement to the next, that combination is difficult to achieve any other way.

It also means that as your firm’s service offerings evolve or requirements change, you update the template rules rather than rebuilding your entire template library. The logic lives in one place and propagates to every project created from that template going forward.

Conditional workflows in Version 4 bring rule-based logic to project templates, so the right tasks are triggered automatically based on project type, jurisdiction, service line, or any other property your firm uses. The result is fewer templates to maintain, no manual task adjustments after launch, and a consistent task structure on every project, regardless of its complexity.

Book a private tour

See conditional workflows running on a real project template

The difference between a static template and one that responds to project properties is something that makes more sense in a live session than in a description. You tell us how your firm currently handles project variety, and we’ll show you how conditional logic handles it automatically.

• Watch a single template trigger different task workflows based on project type selection in real time
• Walk through how conditions are configured and how rules are built into the template
• Ask anything about jurisdiction-based logic, service line combinations, and how existing templates can be updated
• Get a clear picture of how many templates and manual adjustments this replaces for your firm before you commit to anything