Share
Report
10I'm looking for advice on whether to be using Status Reasons or stages in Business Process Flow (BPF) for a specific project, using MS Dynamics CRM 2016. It is for the case entity, and we will be wanting to use enhanced SLA (and using the Pause conditions). Now, there is a specific flow that they have for their cases, and on the one hand I want to use a BPF so that the users are reminded of/walked through this flow of stages (and help any new staff, etc.), but on the other hand, the Pause for the SLA timer only works for Status Reasons (as far as we're aware), so one of the developers wants to use status reasons instead (well there is already a BPF, but with much less stages than we are otherwise considering adding). But I am worried that using many Status Reasons a) it doesn't inform the flow and b) the onus in all on the user to remember to keep changing the status reasons or else it will throw off their KPIs. They want status/stages such as Assigning Analyst (or Waiting to Assign Analyst), Analysis, Assigning Investigator, Investigation, and a bunch more (where the assigning/waiting on assignment ones are excluded from the kpi/timer). (for now for requirements they just want the total time on the case, but they do also have on-paper times for each stage/status, so i can see them eventually finding it helpful to have the kpi/timer for each).
Now, the business does have a flowchart of steps that are grouped into 8 stages. Though if I used Stages rather than Status Reasons for all of the above, we would be breaking down their documented stages/categories into more stages of a BPF (and the businesses "Stages" would be the BPF's Categories).
So, i think i'm debating either using more stages in the BPF and also having Status Reasons to match, which get changed automatically when you change BPF stages (which seems a little redundant, but it gives both benefits of using the BPF for the flow, as well as having the Status Reasons for the SLA/kpi pause), OR only using Status Reasons (with the businesses very general category/stages for the BPF stages), though am worried that users will forget to change the status reason every step of the way. Am I right in wanting to have all those things in the BPF, or is that too specifc?
Also, a 2nd debate and complication is that we also need a multi-level approval process. Which in the 2016 version I can either do via a customized Approval activity (like a task), or as a bunch of additional stages under an Approval category. The environment is shared with another business unit that does their own separate things, and so doing the task option would mean that they would also have that item but also that it has to use the same activity read/write securities, so if we want to lock it down so that only the task owner can approve the task or task stage, then it would have to be those permissions for all activities for everyone. which is why i was leaning towards putting the approvals as more stages in the BPF and for each of those stages assign the case owner to that Business Unit of managers. sorry, i know that's a side issue. just that my BPF is going to be long, but i think that serves the purpose for both debates? (more interested in the answer for my 1st problem, stages vs status, but also feel free to weigh in on the approval piece). Thanks!!
All responses (
Answers (
