Just a quick question I wasn't able to Google-fu about CRM 2011 plug-in behavior. If I have a plug-in on, let's say Account, that updates another entity, let's say Contact, plug-ins registered on Contact messages will fire (correct?).
If those plug-ins are registered as synchronous will the Account plug-in have to wait for the Contact plug-ins to finish executing before it's execution is completed? Does the chaining of the plug-ins create a blocking situation?
Chris,
To your first question that plugins registered on Contact messages will fire? That is correct. and if you have selected synchronous that meaans:
The account plugin gets triggered makes some changes to the contact entity, and then the contact entity plugin makes some changes to contact entity. Only if the contact plugin finished without error then all the changes will apply, if not the contactplugin does a roll back aswell as the Account plugin. So no changes will be applied.
With Asynchronous it means that if the account plugin is finished, regardless if the contact plugin finishes without error, the changes apply to the contact entity.
Related
Currently I am developing an Add in for Outlook and I have implemented onSend event. Since it is UI-less and it is always triggered, I was wondering is there a way to only trigger it for Appointments not emails? This is because user experience, for them not to have "Add in" triggered when messages are created and sent out.
There isn't a way to restrict On-send to just appointments. One workaround, which I'm sure you are aware of, is to no-op the event handler if the item is a message. This doesn't solve the problem of the add-in running on messages.
We track Outlook add-in feature requests on our Tech Community Page. Please submit your request there and choose the appropriate label(s). Feature requests on Tech Community are considered, when we go through our planning process.
I am using Dynamics 365 Online Trial. I have a requirement to trigger a plugin when the user is disabled/enabled in CRM. So I have created the plugin and registered the same in User entity SetState and SetStateDynamicEntity messages but the plugin is not triggered.
Plugin Registration Steps:
Message: SetState & SetStateDynamicsEntity
Entity: systemuser
Event: Post-Operation
User records have been Enabled/Disabled in CRM (through O365) but the plugin is not triggered.
Also tried with update message plugin for the same requirement, but that is also not triggering the plugin.
Updated Plugin Registration Steps:
Message: Update
Entity: systemuser
Event: Post-Operation
Filtering Attribute: All Fields
Image: Pre Image
Any help would much be appreciated.
You are on the right track to be using the Update message, as the use of SetState is deprecated (as far as I know).
You might find this article interesting. It states:
When update requests are processed that include both state/status
fields plus other standard fields, workflows registered for the Update
message execute once for all non-state/status fields, and then once
for the state/status fields. Workflows registered for the Change
Status step continue to be triggered by updates to state/status
fields.
However, users may be a little different as they have the isDisabled field. Maybe try filtering the trigger to just that field. And if that doesn't work, try triggering on a "regular" field just to make sure that you plugin can fire on the Update message.
Full disclosure: I have never had to write a plugin that fires on disable of a user.
However, since it does not seem to be firing when filtered down to isDisabled, I checked to see if an OOB workflow could trigger on that field. It is missing from the selection dialog, so apparently not:
You might want to get a Microsoft support ticket going to see what they say, but in the meantime, perhaps register it to trigger on ModifiedOn, with a pre-image and check for yourself whether isDisabled changed.
We also experienced this issue, we were unable to achieve the plugin route.
Then we did a workaround scheduled job (to run every 24 hours) with SSIS + Kingswaysoft package to query the disabled users.
This system user status change is not getting trapped in Dynamics platform as we are not sure how the O365 changes like license removal or AD changes like account removal is getting replicated into Dynamics platform.
You can try registering a plugin on Update of userlicensetype is SystemUser entity
We have server-side synchronisation set up for our Dynamics 2016 on-premise instance, and it is correctly sending emails from a Case, and tracking replies from the customer. However, when an internal user replies using Outlook (without the CRM add in), their responses aren't being tracked. This means that the email conversation consists of an initial "outgoing" email, followed by only incoming responses.
The full scenario is:
Internal user sends an email from a CRM Case. Email tracked in CRM
Customer replies to email. Reply tracked in CRM and goes to internal user's Outlook
Internal user sends a reply from their Outlook. Reply is not tracked in CRM
Customer replies to email. Reply tracked in CRM and goes to internal user's Outlook
Is it possible to allow the Internal user's replies (point 3) to be tracked in CRM without installing the Outlook add in (i.e. so it also works from the Web/mobile versions of Outlook)?
I believe you cannot do this without Outlook client as per Jukka.
Without the CRM Outlook client you can’t get the information into CRM without copy-pasting it from one window to another in the aforementioned scenarios. No synchronization technology will help you here, since CRM is unaware of the item until it has been brought into its world. The “Track” button is a client-side feature that you can’t utilize with any server-side solution, which means there’s no way for a user to select an email, appointment, task or contact from the Exchange server that he or she would like to promote into a record in CRM. Since the the record wasn’t “born in CRM”, it just can’t find its way there.
Last resort would be Smart matching with Tracking token, which may help you in this scenario.
Update:
Customer reply is going to reach CRM through a monitored queue. You can read a lot & get clarity from the above link.
Deploying a solution like the CRM 2013 the server-side synchronization will take care of moving items like calendar appointments and contacts back and forth between the end-user client device and the central CRM database, but it only applies to items that already exist in the realm of CRM. What I mean by this is that the item was either originally created directly in the CRM application or it was received via a monitored location like an email queue.
Your expectation is right, it should be tracked. I would open a ticket with MS & solve this.
Once the item is in CRM, server-side sync can take care of tracking the subsequent updates to it. A re-scheduled tracked appointment will get updated with the new date, regardless of whether you change the date via CRM or your mobile phone calendar that’s linked to Exchange. An email thread with a tracked message and a tracking token ID injected into the email subject line will have the next replies automatically synchronized into CRM
I have heard back from our Microsoft Partner, and they say that this scenario isn't possible. By design, it'll only track incoming emails to CRM, or outgoing if sent from within CRM itself.
I have a plugin that fires on Pre-Validation for Account that works fine in all instances I can find, except when a Lead is being qualified. It is creating the account, via the OOB process, but the Account's pre-validation event is not being triggered.
Is there some other way to capture this event? The Pre-Operation works, but I want to perform the work outside of the transaction, not inside...
This is probably not a bug but "undocumented" functionality.
I'm fairly certain that the QualifyLeadRequest message handles the security check to create accounts, contacts, and opportunities so there is no need for a Pre-Val operation when creating the records - if the user didn't have permission to create the records the QualifyLeadRequest request would have failed.
That said, even if it did fire the pre-val plugin you would still be in the transaction because the transaction starts before the QualifyLeadRequest pre-op and commits after the QualifyLeadRequest post-op (therfore, everything that happens between those - including creating the account - is in the transaction.)
Thus, in this case there would be no difference between stage 10 (pre-validation) and stage 20 (pre-operation.)
We're building a system that is tightly integrated with a clients CRM install, and need to have a callback fired when an entity is updated, created or deleted. This callback will ideally send the entity name and id to an external service via a HTTP get request.
I've not found any docs online that help - can anyone point me in the right direction?
You're looking for plugins: http://msdn.microsoft.com/en-us/library/dd393295.aspx.
You can register a plugin on Create, Update, Delete, etc. of an entity, and then run any custom code you'd like. You'll definitely have access to the entity name and the id, as well as fields that were updated, information on the user who initiated the call, etc.
Just know that in MSCRM 3.0 & 4.0, plugins run outside the actual database transaction, so it's possible the event could fire in CRM, but the plugin fails and the event still goes through. In MSCRM 2011, they run inside the transaction, and can stop the CRM event from happening if need be.