Task-based process flow or Record-centric design

Question

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.

Dave Lewis · Accepted Answer

I don't know that you really need to think so much in a VS. mindset. The two aren't exclusive, or in contention, but rather complimentary. 
 You can think of it as a record-centric, task-based flow. Or you can think of it as a task-based, record-centric flow. Or you can choose not to concern yourself too much with the order of the adjectives. At the end of the day, you're creating requests. Requests for Overtime, Annual Leave, Travel, etc. Now, each of these requests will take the form of a tangible thing that someone can write and someone else can read. Maybe the simplest way to get these are simple Records. 
 From your response it really sounds like that's already what you're doing. You have a Record. You could just process that Record in a linear sort of fashion. Make it the best durned Record and Linear process it can be for the task at hand and don't worry about which one is "Centric". Use Related Actions where most appropriate, and assign tasks to folks in a persisting process flow where most appropriate. The ratios between the two can be WHATEVER YOU WANT. 
 Now, you said they all follow basically the same workflow? That's FANTASTIC! You know what this gives you the opportunity to do? Make one workflow, and reuse it (or most of it) for EACH of the different kinds of requests. That's how you get efficient! Reuse. Recycle. Then customize to cater to the slight differences of each one. It might be a different flow for each that reuses a tremendous amount of code from the others, or a single process model that handles all of them but sends different ones along slightly different routes. You'll know how closely you can map them to each other.

Task-based process flow or Record-centric design

Top Replies