Hi Community,We have about 15 legacy Workflow applications that we're going to convert into Appian workflows. Most, if not all, of these workflows are mainly linear Task-based HR workflows (like Request for Overtime, Request for Annual Leave, Travel Request, etc).
We already converted two of the big workflows using the Task-based workflow Process design pattern. The remaining ones generally follow the same process steps: Start -> Submission Sub-Process -> Approval 1 Sub-Process -> Approval 2 Sub-process -> Process Request Sub-Process -> End Flow.
Now, some of us are at least looking into whether it's worth it to do the remaining workflows (and refactor the two workflows already in production) using the Record-Centric design where all the sub-processes will be "Related Actions" instead of as Tasks. I understand that the Record-Centric approach is the preferred method of Appian but with our old workflows being all Task-based workflows, there are numerous reasons why I prefer continuing with this approach.
Reasons I can think of(but not limited to) are:1) Record-centric approach is perfect for Case-Management style apps, but ours are Linear Task-based. We still use Related Actions by the way for a lot of adhoc tasks on the record during the flow and after the flow has ended.2) Since there are no Tasks generated from Record-centric approach, user-experience will be affected negatively especially the approving managers as they are used to just clicking a link to the task from their notification e-mails or having a nice one page where all their assigned tasks from different Appian applications are shown. 2b) The legacy workflow plus our other non-Appian workflow type applications have their approval process behave similarly to Appian's task-based approval, so this was endorsed by our Business Analysts when we first did our first Appian workflow.3) We don't have memory issues right now that merit this change and as long as we follow the Appian playbook of creating memory-efficient models(including maybe using Modular design or Flexible design in some cases), the future forecast is that we will not have memory issues at all.4) We already converted two legacy workflows (one of them being the most complex one), so refactoring these two if we switch to Record-centric will bring extra work (and pain).
What about you guys/gals? Is there a case that I don't know that would warrant a change to the new design approach? Is there even a compelling case that a Record-centric approach should be implemented for a Linear Task-based workflow? Thanks for your help.
Discussion posts and replies are publicly visible
As Stewart mentioned, the move to a record-centric design is about eliminating long running processes and allowing a wider audience to interact with a record/case concurrently. Without knowing details on your specific workflows it will be hard to give you advice on a given workflow, but if your HR processes are focused on specific individuals or groups approving tasks in a structured workflow, it likely still makes sense to leverage a clearly defined workflow and task structure within your processes.
If you aren't already, it probably also makes sense to have some sort of HR record that tracks your processes even if you aren't kicking off a lot of related actions directly from the record. You may also want to review your HR processes to see if you can build something more generalized that will work across multiple workflows rather than building out each individually. In my experience, it takes more time to do the design and analysis for combining HR functions into one process that is smart/dynamic, but it will generally pay dividends in not having to build and maintain every individual workflow.