function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
BrenzoBrenzo 

Case ownership is being transferred for NO (some) reason

After spending close to two hours on the phone with Salesforce support, they suggested I should post here to find a solution to my problem. So now I am at the mercy of you kind developers prowling these boards and I am hopeful that together we can find a solution to my problem.

The Problem
Case ownership is transferring between users and my default support queue without the user's input, however, it appears as if the user is the one transferring the case. This can occur minutes after they initially take ownership, and sometimes it happens several hours later. It occurs with both open and closed cases, the latter be especially frustrating since the newly assigned owner will go to work the case without realizing it's already been closed. I have also verified that this is happening both during and after hours - when users are no longer logged into the system  - so I know that they are not the ones transferring the cases despite the Case feed suggesting otherwise. 

Investigation Thus Far
Assignment Rules - Even though I assumed this had nothing to do with assignment rules, I double checked. Sure enough, there are no active assignment rules - nor are there any Case page layouts where the 'Assign using active assignment rules' is visible and/or checked by default.

Apex Triggers - Salesforce support suggested this was the cause, which makes sense, but I looked and there are no active Apex Triggers that I have written / implemented, which would cause this behavior. In fact, there are only three (3) Case object triggers, all of which are managed by installed packages, and none of which are desigend to do anything with regards to Case ownership (one is related to our mapping software and the other two are for a contest/gamification application)

 
I just want to thank everyone in advance for any support or guidance you can provide here. Please let me know if there is anything else I should provide that would help diagnose the issue here.

Thank you.

Ben
 
MandyKoolMandyKool
Ben,

You can further investigate by adding "Case History" related list on page layout. You can see who is doing the owner changes. If it appears to be the same user, you can also look at workflow rules and process builders for Case object.

As you said that the changes are happening after hours - for this you can check all the running/scheduled batches in your system, which might have logic for switching case owners.

Hope this will help you find the root cause of this.

 
BrenzoBrenzo
@MandyKool

I've already added 'Case History' and track any ownership changes. It's appearing as if the user / case owner is the one transferring ownership, but I know for a fact that they are not (I've asked them and as mentioned above, many of these ownership transfers are happening after hours when users are not in the system.)

I do not have any Process Builders running the case object that would transfer ownership, and there are no Workflow rules either (though I do not believe it is even possible to change owenrship with a workflow rule.)

Appreciate any other suggestions here.
Alain CabonAlain Cabon
Hello Brenzo,

1) There is a new way to get the events: https://trailhead.salesforce.com/module/event_monitoring

2) An asynchronous job is queued. It will be executed at once or more rarely a long time after the queuing. 

Search all the annotations "@future" in your Apex code.

3) Setup : Quick search  "Jobs" : to see your asynchronous treatments history and the scheduled jobs.

4) Among your App Exchange applications (quick search: Installed Packages)?  (https://appexchange.salesforce.com/listingDetail?listingId=a0N30000008Z4H9EAK) They can change the case owners.

Regards
Alain
BrenzoBrenzo
Hi Alain,

I followed your suggestions and there is nothing that I could find to suggest as to why these cases are reassigning.

However, I was speaking with one of my customer service agents earlier today and we noticed that the when they mark themselves as 'Available' in the OmniChannel that cases appear to be transferring into their name from the Support Queue even though they are not actually accepting the cases within the OmniChannel window. When the agent marks themselves as unavailable in OmniChannel, or leaves for the day, these cases (and only these cases) are pushed back to the Support Queue and made available for automatic assignment. I have double checked that the default presence configuratoin is not set to automatically assign cases, and yet it would appear as if the case ownership is changing to the agent - at least temporarily.

Appreciate any further inside here!

-Ben
Benny XieBenny Xie
@Brenzo
Not sure if this issue was ever resolved but I'm experiencing the same issue. Would love to see any solutions that you may have came across for this problem.
Nora Nicklis 24Nora Nicklis 24
I've had the same problem and found out that this is standard Omni Channel behavior. 

If your agent is available and a case is proposed to them (even if they don't accept the case) in the background the case gets assigned to them and then it gets assigned back to the queue. In the case history this will show as two changes of ownership (which can be quite confusing since nothing really happened) 

There is an article on this here: https://help.salesforce.com/articleView?id=000247502&type=1

One way to solve this would be with a process on the AgentWork Object. For that, you'd need an additional field on the case (something like "Owner History") you could filter AgentWork records that get accepted and based on that criteria update the "Owner History" field of the case with the current Owner. That way you'd filter out all of the changes that only happen because Omni Channel tries to assign a case to an agent. 

However, if you also have manual ownership changes (not only through Omni Channel) you'd miss those. I've not really found a solution that would also allow covering this.