Tuesday, 21 February 2017

How to execute a plugin as the logged in user?



Quite often I have seen people asking this question and they complain they have used the right piece of code but still CRM is using the system account instead of the logged in user to execute the plugin.
This is what they had used in their plugin code:

IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
            tracingService = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
            IOrganizationServiceFactory serviceFactory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
service = serviceFactory.CreateOrganizationService(context.UserId);

Correct code should have been used InitiatingUserId rather than the UserId. So it should be
service = serviceFactory.CreateOrganizationService(context.InitiatingUserId);
 instead of

service = serviceFactory.CreateOrganizationService(context.UserId);

Enable activity menu ribbon buttons for custom activity entities

Enable activity menu ribbon buttons for custom entities
If you have enabled activities for a custom entity in Dynamics CRM you might want those activities to be created from the ribbon menu without navigating; like this:


Then you have to follow these steps:
First install Ribbon Work Bench (you can download it from http://develop1.net/public/rwb/ribbonworkbench.aspx)
Then create a solution and include only the entity you want to add ribbon buttons.
Open ribbon work bench and open that solution you created.
There you have to add a command for each activity type. E.g. Email, Phone Call, Task, Appointment etc. No need to create any buttons. Commands will do the job.



Email Button:
Command Id: Mscrm.SendEmailPrimaryRecord


Action: Javascript Command
                Function Name: Mscrm.RibbonActions.addActivityOnForm
                Library: /_static/_common/scripts/RibbonActions.js
                Parameters: Int Parameter, Value: 4202





Display Rules:


 1.  Mscrm.AddActivityToPrimary


Id: Mscrm.AddActivityToPrimary
IsCore: False
Steps:



i)                    EntityPrivilegeRule
-          AppliesTo: PrimaryEntity
-          PrivilegeDepth: Basic
-          PrivilegeType: AppendTo

ii)                   EntityPrivilegeRule
-          EntityName: activitypointer
-          PrivilegeDepth: Basic
-          PrivilegeType: Create

iii)                 EntityPrivilegeRule
-          EntityName: activitypointer
-          PrivilegeDepth: Basic
-          PrivilegeType: Append

iv)                 EntityPropertyRule
-          AppliesTo: PrimaryEntity
-          PropertyName: HasActivities
-          PropertyValue: True

Mscrm.WriteActivityPermission



Id: Mscrm.WriteActivityPermission
IsCore: False
Steps:
i)                    EntityPrivilegeRule
-          EntityName: activitypointer
-          PrivilegeDepth: Basic
-          PrivilegeType: Write
EnableRules
       
   1.


Id: Mscrm.FormStateExistingOrReadOnly
IsCore: False
Steps:
i)                    OrEnableRule:





OrGroup 1


OrGroup2


   2. 




Id: Mscrm.AppendToPrimary
IsCore: False
Steps:




Follow the same pattern and create commands for each activity type. Only difference is the integer parameter value needs to be changed based on the activity type.


How to tackle Concurrent Business Process flows

Dynamics 365 has introduced the new feature of Concurrent Business Process Flows. Here is a couple of good articles on that: http://dev...