To bypass the issues around custom coding, enterprises often resort to using business process management tool as a go between to create workflows that support complex rulesets. However, unlike BMP solutions, most CLM platforms out there use workflows with hardcoded states, essentially indicating that they cannot be configured. Only new workflow states can be added, which requires engineering intervention. As a result, agreement workflow states that are visible on the UI, search filters, search results, and core reports cannot be modified. Some workflows are built on a Windows workflow foundation, which has its own set of technical limitations that could hinder future portability.

Even if a new workflow is coded and created by the engineering team on demand, there’s a strong possibility of data corruption during state transition of workflows. Such issues can only be addressed through technical redressal of data associated with thousands of contracts. In most cases, due to time constraints, this issue is addressed with data fixes in the customer’s production environment and is not patched at a platform level so it can benefit all customers.

End users also face considerable difficulty managing a fundamental component of a workflow – the underlying rules engine. These are often notoriously effort- and time-intensive to set up and maintain by non-technical users, especially if they do allow rules to be updated or modified through an intuitive interface. This in turn leaves very little room for users to validate the new workflow ruleset without actually executing the flow on system in a ‘live fire’ exercise. For enterprises with a mature CLM practice, this should be considered a dealbreaker especially if the solution vendor offers to configure the rules engine as a chargeable service (because they need to hardcode the changes into the system).