Edit: On thinking this over, the most logically correct approach is as follows:
- Create a self-referential lookup field/relationship in the
PhoneCall
entity (the target of which is PhoneCall
), called something like new_OriginatingCall
. This will provide you your trail of follow up phone calls.
- Create a
Create
, pre-operation/validation plug-in on the PhoneCall
entity that checks for the existence of a value in the new_OriginatingCall
field. If it exists, populate the to
and from
fields from the originating PhoneCall
.
- In the javascript attached to your button, create a new
PhoneCall
with the new_OriginatingCall
populated.
This way, no matter how a follow-up call is generated, the to
and from
fields are always populated correctly server-side.
Edit: See below for a sample of how to retrieve and set PartyList
s via Linq.
// newPc is the Target entity of the plugin.
var pc = xsc.PhoneCallSet
.Single(x => x.ActivityId == newPc.new_OriginatingCall.Id);
// pc is now a copy of the original phone call.
// Have to make new activity party lists because the activity parties attached to
// the original phone call activity have the activity id set to the original
// phone call.
// Trying to attach them unchanged to the new phone call (which would have a new
// activity id) results in a FaultException.
var to = pc.To.Select(x => new ActivityParty { PartyId = x.PartyId });
var from = pc.From.Select(x => new ActivityParty { PartyId = x.PartyId });
// Prep the new phone call.
PhoneCall pcNew = new PhoneCall
{
To = to,
From = from,
Subject = pc.Subject,
ActualDurationMinutes = pc.ActualDurationMinutes,
DirectionCode = pc.DirectionCode,
PhoneNumber = pc.PhoneNumber
};
// Create the new phone call.
service.Create(pcNew);
If you can more easily assemble PartyList
s in .NET than in javascript, I strongly recommend using one of the two best answers suggested in the great question Call C# Code from Ribbon JScript CRM Online 2011 (i.e. trigger your code via the creation of a "plugin" custom entity or include a field in the PhoneCall
entity that is set via javascript, and on update, triggers a plugin that examines the state of that field and reacts accordingly).
I've used both approaches often, as it's often complicated to achieve similar results in the CRM with javascript.