[SalesForce] Adding Activities on Leads in Salesforce Lightning

To borrow a consulting cop-out, I think the answer depends on your business processes and objectives. Girbot made a great recommendation to engage the business in conversation on this topic. Or, put in other words, please consider your organization's unique context.

With that said, let's explore (thinking out loud) a few business considerations, and then examine some options. Hopefully we'll arrive at some guidelines for using the Parent Case field, that you can apply to your unique organization.

Why do front-line staff care?

Typically front-line staff care about two things:

• Avoid the stick. This means completing the work, so that they don't get disciplined or terminated for dropping the ball with a customer.
• Get the carrot. This means getting credit for the work they did, in a way that maximizes the impact (read, calculated result) of the work on any incentive payouts for which they are eligible.

Both of the above concerns usually drive a need to have a system that allows for efficient routing and handling of cases, so we assume that users want to close cases as quickly as reasonable.

Why do managers care?

Support managers usually care about a couple of things:

• Volume and quality. How many cases are coming in? And is every case is closed in a timely manner, to the customer's full satisfaction?
• Address strong and weak team members. Since staff live in the world of customer service via cases, the data captured in cases should help identify or provide evidence to support strong and weak team members.

Managers usually look at data in aggregate, which in Salesforce means using Salesforce1 Reporting (formerly known as Salesforce Analytics).

Four technical options

The hypothetical call about a broken printer and a new monitor you described can be logged in one of the following ways:

1. 1 case for both issues (broken printer + new monitor)
2. 2 cases, unrelated, one for each issue (broken printer, new monitor)
3. 2 cases, one parent and one child (user's choice for which gets created as the child case). This assumes that your Fulfillment department uses the Case object to manage new monitor requests and not something else, like the Order object.
4. 3 cases, one parent case for the call (broken printer + new monitor), and two child cases (broken printer, new monitor). This is similar to what Girbot explained in his comment, using the case hierarchy to split a large problem (the parent case) into smaller problems (child cases).

Option 1: Probably not what you need

You've already noted that two departments are involved, one for the broken printer and one for the new monitor. If you're not using Case Teams, you probably will need or want to create a separate case and assign that to the other department.

Plus, if your organization reports on the number of cases handled by reps, chances are those reports are based on Case Owner, in which case the rep in the supporting department won't get credit for working on the case.

Option 2: Acceptable, not great

Having two cases solves the work routing and crediting problem, to distribute work to two departments. However, at a glance you won't be able to tell that a related case was created. Furthermore, you're building a habit that is not conducive to introduce any kind of automation for related cases (e.g., time tracker roll-ups).

Option 3: Acceptable, better than the previous option

Basically this is the previous option but with a link between the cases. The relationship allows for quick visibility to see that a related case exists, and the relationship would facilitate any kind of "related case" automation you may want to add.

To keep things clean, and to simplify life for the customer by just providing the customer one reference number (i.e., Case Number), I suggest:

• The person who handled the inbound call owns the parent case.
• The parent case number is given to the caller.
• Since caller only has one case number, all activities are logged on the parent case.
• The parent case owner creates the child case, and assigns it to an appropriate user or queue
• Internal collaboration on the child case happens via Chatter or Case Comments
• The parent case remains open until the child case is closed

Option 4: Probably overkill

If only two people are involved, this would really seem like overkill. However, for more complicated problems or situations where the primary support rep is not the one working to solve the problem, you may want to go this route.

One example that comes to mind is a technical support call that reveals two deeper, distinct problems, requiring involvement from separate R&D departments. I may call Premier Support about a Visualforce page, and that ends up being escalated separately to the Visualforce team and the Apex team.

Direct answers and closing thoughts

Sorry for the long-winded response, but here are my direct answers to your questions. It bears noting that in the scenario you described, I think the third option (2 cases in parent-child relationship) is probably optimal.

Do I duplicate the Activity, marking one as "real" for statistical purposes?

No. I don't recommend duplicating activities (i.e., Task records). Log customer interactions only on the parent case.

Do I make a shell parent Case, two child Cases, and keep the initial call on the parent (and then provide a UI on the child cases to see the activities on the parent)?

No. This is the fourth option I described, and I do think it's overkill for the scenario you described. Using two cases will probably meet your business requirements.

Do I do something else entirely?

Yes. Create two cases in parent-child relationship. This makes it respect the reality that you described, "as far as the caller is concerned, [we'd] like to treat this as one call." One case number given to the customer, two case numbers known to the organization.

I don't think it's possible right now with GA functionality. Your only option might be Lightning Extensions, currently a pilot feature. Or, for a much higher LOE, you could build a Visualforce page for an action override.