0

I need to handle a scenario where a Sales Rep will raise a case for service activation for a customer. Such a case will have the following steps -

  1. Team A will validate the details and then pass on to Team B for the actual activation. SLA for Team A = X

  2. Team B will activate the service in an external system, and update an activation ID in SF. SLA for Team B = Y

  3. Team C to call and communicate activation to the customer. SLA for Team C = Z

Now there will be many case types like this, each having a different mix of teams and SLA's and even associated Work Orders in some scenarios. A key requirement is to be able to track the overall request SLA and team wise SLA.

What will be the most scaleable way to handle this in salesforce?

Option 1 :

Have a Parent Case for Service Activation and have team specific sub-cases under the parent case umbrella. This would allow for future flexibility, if any team wants to further expand on their individual processes.

The Parent/Sub Case mapping will be maintained in a custom "Case Rule Engine" that we build using apex and custom objects. The sub cases will also trigger status updates on the parent case via apex and similarly from Parent to Child.

This "Case Rule Engine" may very soon become an apex monstrosity.

Option 2 :

Have a single case represent the request and have different milestones representing the work to be done by different teams. Whenever a team closes their milestone, use apex to update the case owner to the next team.

This seems to me like a more standard way of doing things and might work well when the case needs to flow sequentially across teams but if teams need to work in parallel might pose a challenge, like who should own the case, what if they overwrite any information etc.

Option 3 :

Have a single case with multiple tasks representing the work to be done by different teams. This does not work for us as the task cannot be assigned using Omni-channel to the available team members. Also SLA tracking might be a pain using tasks.

I want to go with option 2 but just feel that at some point it will become tough to scale or extend. I am sure this is a very common scenario in service cloud and would like to how some of you have handled this in salesforce.

2

You can use a combination of features that facilitate this process, all without ever touching Apex. I would likely recommend parent/child cases in order to notify certain teams of work to be done, which can all be aggregated back to the parent via Process Builder. Milestones can track SLA, Omnichannel Routing and/or Assignment Rules and Queues to get the cases to the right people. Process Builder can help bridge many gaps you might encounter. Without knowing your specific process, of course, it's hard to be 100% certain that you don't need Apex, but in my experience, most orgs can work out a process using only standard features.

  • I lean towards apex because I expect a high volume of cases being bulk uploaded and pushed via external apps. In my experience Process builder can very easily go off the rails in case of volume. My larger concern is do I create sub cases or do I keep rotating the parent case across teams? – Vic Jul 16 at 5:01
  • 1
    @Vic Moving a case around is more of a "one person at a time" system. If you have multiple teams that may need to work in parallel, child cases may offer better visibility in reports and facilitate case management. The older "case teams" feature works almost as well, but you can't assign individual tasks to people to determine performance metrics, etc. The downside is that multiple cases might be harder to manage overall. You might need an actual consultant to determine which approach will be best, or some user acceptance tests to see which works better. – sfdcfox Jul 16 at 5:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.