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
There are several reasons why you might want to move to Record-centric vs. Process Centric designs. Here's a thought experiment to help:
A Financial Services company sells 25-year Mortgages to its customers. Why would you NOT have a process running in a process server for TWENTY-FIVE YEARS! And not just one, but one for every Customer who had a mortgage with you?
That should help you start thinking about some of the reasons to choose a different pattern. You've already identified some of the other (non-linear processes, Case Management patterns).
Does that help you get started?
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.
Thanks for the responses so far guys. In our particular case, every employee is an Appian user and in every user's main Dashboard page will be different links to each type of request (ie, Overtime Request, Leave Request, Travel Request, etc).
So for example, an employee starts and submits an Overtime request for himself for a particular day, the process then creates an approver task and assigns it to the line manager. Daily reminder e-mails are sent to the approver if he/she hasn't actioned the task. Our Appian Record Type in this particular case is the Overtime request. So before the line manager approves the request, the two Related Actions available to the record for the employee (the initiator) are "Change Line Manager" and "Change/Cancel Overtime Request". Once the request has been approved, that's practically the end of the process. There will not be any long-running processes in our case.
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.