Workflow platforms come in a variety of sizes. At first glance, determining what makes one different from another can be difficult. While nearly all allow you to build simple applications, most stop there. Most legal departments that have purchased these platforms don’t realize their limitations until after building and deploying their first few applications.
Several areas distinguish common workflow tools from enterprise-capable platforms, which can become a cornerstone of your department’s technology stack. Here are just a few:
For many tools, dragging and dropping capabilities exist for basic functions only, after which coding requirements begin. We have found that this occurs much more quickly than anticipated by the purchaser in most cases.
These tools typically have objects (or shapes) that include embedded rules that can be configured simply. As complexity increases, objects do not exist. A developer begins to write code to address the complexity. This lengthens the development process, and creates a dependency on IT. Simply put, as soon as code is written and complied, speed and agility decline.
Basic workflow platforms often leverage SharePoint (or others) to serve and store data and content. Although it appears to be a simple task to create a list or library, due to platform limitations this isn’t effective in mission-critical, broad deployments.
The goal for the department should be to build minimal maintenance applications that can scale to support every employee in the company.
Most workflow platforms have a very simplistic user access model. This creates user experience and security challenges in wide deployments. Support is required for users, groups and roles that are supported by Active Directory and Single Sign-on. MyLegal supports an additional personalization model that further improves the user experience.
A common challenge with workflow platforms is the lack of support for application runtime support. These frustrations often arise once legal departments have deployed their first few applications.
Administration capabilities need to extend to inflight workflows. Instead of telling the user that they need to start their process over again because they made a mistake, admins should have the ability to roll back the process to correct the error. Should parts of a workflow need to be skipped for a process instance, the administrator should be able to accommodate that. Should there be a need for a new version of the application, it should be able to run along with the previous version. And should there be a need to migrate running process instances to a new version, the administrator should be able to accommodate that as well.
Everything you need from legal all in one place.
