Most cases are one agent's work; the interesting ones aren't. xMatix gives a case four collaboration records or actions with different weights: followers, team members, side-conversation threads, and merge for duplicate cases. They preserve who was involved and the context attached to the case, but descriptive fields such as notify, role and access level are not substitutes for configured notification delivery or platform security.
Collaboration happens around the case rather than in a disconnected chat room, so the quality of this shared context matters. The case identity is the reference followers, team members and side conversations should quote; account and asset prevent a specialist from reasoning about the wrong customer or installation; subject and description provide the common problem statement. Classification and urgency let a new participant understand the handling posture before reading every event in the timeline.
Before adding people, update the case so it explains the current symptom, evidence already gathered, customer commitment and next decision required. Use Follow for awareness, a team member for accountable work alongside the assignee, and a side conversation for a focused exchange whose result must return to the case. When the exchange concludes, record the useful conclusion in the timeline or resolution evidence; the collaboration mechanism proves who participated, while the case must remain understandable to the next owner without access to private recollection.
Following a case
Follow puts you on the case's follower list with Notify on change recorded; Unfollow mutes that follower record. Re-following unmutes it. The current case service stores this notification preference but does not itself dispatch follower notifications, so use tenant automation where a real alert is required. Following does not grant access to the case.
Team members
Add Team Member attaches a colleague to the case with a role (default Collaborator) and an access level label (default Read), and optionally marks one member primary; Remove Team Member detaches them. These fields describe participation but do not grant record permissions — security profiles and record security still decide access. The team list remains distinct from Assigned To, which is the single working owner.
Side conversations
A side conversation is a stored sub-thread on the case: its own subject, channel label, open/closed state, and messages with direction, recipient and sent-on metadata. Start one (Start Side Conversation), add replies, and close it (Close Side Conversation) when the consultation is complete. The current service persists the thread and messages but does not transport them over email or another channel, and it does not enforce privacy beyond ordinary case security. Use your configured messaging integration for delivery, then record the useful conclusion on the case. Side conversations remain attached through a merge.
Duplicate detection
Find Duplicates on a case surfaces other cases likely to be the same issue. If your administrator has authored deduplication rules for cases (Setup → Feature Hub → Platform → DeDuplication Rules), those decide the matching — field by field, with exact, case-insensitive, starts-with, contains, or first/last-characters matching, combined with all/any logic. Without rules, the built-in matcher proposes cases sharing this case's contact, account or phone number, excluding records whose status is exactly Closed and records already merged away. Other end-state labels, including tenant-added ones, are not automatically excluded. Either way the list shows the most recent candidates with why each matched.
There is also a Duplicate action with the opposite purpose: it clones the case — business fields, classification and relationships — into a fresh New case with its own number, linked back to the original. Use it when one reported issue turns out to be two.
Merging duplicate cases
When Find Duplicates (or your own reading) confirms the same issue twice, Merge consolidates onto a surviving master case:
- The duplicates' timeline activities, attachments, team members, followers and side conversations all move to the master — nothing recorded on any duplicate is lost.
- Each duplicate is closed with the close reason Duplicate and linked to the master. It stays openable and shows that it was merged, so an old link or a customer's reference to the duplicate's case number still leads somewhere sensible.
- The master gains a Merged Records view listing everything merged into it, with timestamps.
Merge is directional and deliberate: pick the master first (usually the older or better-documented case), then the duplicates.
Common questions
What's the difference between following a case and being a team member?
Following records an awareness preference; notification delivery requires automation in the current implementation. Team membership records active involvement with descriptive role and access labels. Neither grants security access to the case.
Does merging delete the duplicate cases?
No. Duplicates are closed with reason Duplicate and linked to the master, keeping their own case numbers, while their timeline content, attachments and collaborators move to the master. Anyone opening a merged case sees where it went.
Why doesn't Find Duplicates show a case I know is the same issue?
Two likely reasons: the case has status exactly Closed or is already merged, or it shares none of the matched identifiers — with rules, the rule's fields; without, contact, account or phone. A case in another terminal-looking status is not excluded by the built-in matcher. If matching still misses useful candidates, your administrator can author a deduplication rule over the fields your duplicates actually share.