Branching logic in task set

Hi all -

This may be a pipe dream, but here goes…

We are trying to set up Case Management to be used for Customer Service inquires. No problem creating tasks, task sets, milestones, next milestones, etc. I have reviewed the Epcior Education course as well as relevant bits of the Epicor ERP Application User Guide. I can find no discussion on what I am trying to do, so it may be that I am looking in the wrong place.

Most of our processes are non-linear. That is, they require some sort of “if-then” or branching logic. A customer calls wtih a complaint, the CSR documents everything and sends for management review. The step after the management review is determined by the decision made in the management review. Possible decisions include thing like “Send a replacement part,” “Send an RMA,” and “No further action required.”

I could find nothing on relating task sets to one another and nothing on how to branch a task set.

At the moment, I am using the reason code associated with the Management Review task to tell the CSR what task to create next. For example, if the reason code associated with the closing of the Management Review task is “Send an RMA”, then the CSR knows to add an “Issue RMA” task to the case. If the Management Review outcome is “Send a replacement part,” the CSR knows to add a “Create Misc Shipment” task.

Is there any other way to make this work? It seems really clunky for the CSR to have to do all this. Plus, when they add the new task, it becomes a related task under Notify Customer (the task that currently follows the Management Review), rather than on its own. I did think about creating a dummy task to be used as a Next Milestone after the Management Review and then using a BPM to evaluate the reason code and then update the next milestone from the dummy task to whatever task is appropriate. I know only a litle bit about BPMs, and have used them mostly just to display warning messages during data entry.

So… is it appropriate to use reason codes in this way? Is there a better way that I am completely missing?

Thanks for whatever information you have.

@skhayatt, your scenario isn’t a pipe dream! Your thinking about using next milestones is definitely on the right path. Using your example, define each of the management review outcomes as a separate milestone task, and then specify all of the outcomes as next milestones after the management review milestone. Whichever outcome is typical or most likely, flag that one as the default next milestone. When a user flags the management review milestone as complete, the default next milestone will be selected, but the user can select a different next milestone from the dropdown list.

1 Like

So, it’s not horrible to have a whole bunch of “unused” tasks in an instance of a task set? This sounds a lot less clunky. Thanks. Will tweak my task set in process.

IMO, no, it isn’t horrible to have the unused tasks. AFAIK, to maximize the usefulness of the functionality, you really don’t have any other choice.

FWIW, I dug up an old workflow that might help you by way of an example. In this workflow, both tasks REQ2.06 and REQ2.13 are next milestones for REQ2.01, and both have REQ2.18 as their next milestone, thereby bringing the branched logic back together, but only temporarily. Tasks REQ2.22, REQ2.23 and REQ2.24 all are next milestones for REQ2.18, but each of those branches leads to a separate milestone (REQ2.25, REQ2.26 and REQ2.24, respectively) for completion of the workflow. HTH!

1 Like