I hope there isn’t any one who doesn’t know about security roles and access privileges being in Dynamics space. Most of the people should be aware of doing this via application, in this post, sharing one simple way to grant access to the records using C# code. Please use the below code to achieve the same.
private void ShareRecordtoBUTeamofRequestorUser(Guid Targetid, Guid TargetShare, IOrganizationService orgService)
if (Targetid != null && TargetShare != null)
GrantAccessRequest grant = new GrantAccessRequest();
grant.Target = new EntityReference(MetadataHelper.VolunteerList.EntityLogicalName, Targetid);
PrincipalAccess principal = new PrincipalAccess();
principal.Principal = new EntityReference(MetadataHelper.Team.EntityLogicalName, TargetShare);
principal.AccessMask = AccessRights.ReadAccess;
grant.PrincipalAccess = principal;
//GrantAccessResponse grant_response = (GrantAccessResponse)orgService.Execute(grant);
catch (Exception ex)
catch (Exception ex)
I have commented below lines in try block above and avoid using them because you will get an error for the same…
GrantAccessResponse grant_response = (GrantAccessResponse)orgService.Execute(grant);
An unhandled exception has occurred during execution of the plugin.
An error occured while getting default Team of Requestor BusinessUnit[A]Microsoft.Crm.Sdk.Messages.GrantAccessResponse cannot be cast to
[B]Microsoft.Crm.Sdk.Messages.GrantAccessResponse. Type A originates from ‘Microsoft.Crm.Sdk.Proxy, Version=184.108.40.206, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ in the context ‘Default’ at location ‘C:\Microsoft.Crm.Sdk.Proxy.dll’. Type B originates from ‘Hisol.SCS.CRM.Plugins, Version=220.127.116.11, Culture=neutral, PublicKeyToken=bb2727b96c9cb15e’ in the context ‘LoadNeither’ in a byte array.
Microsoft had recently announced on docs.microsoft.com that using WS-Trust authentication security protocol to connect to your Common Data Service had been deprecated.
So what does this mean??
Firstly you need to note that this only applies to client applications that connect to CDS.
It does not impact your custom plug-ins, workflow activities, or on-premises/IFD service connections.
Below are the places where you need to replace them…
If your code uses Username & Password for authenticating with Common Data Service or an application, you are likely using the WS-Trust security protocol.
- If you are using the OrganizationServiceProxy class at all in your code, you are using WS-Trust.
- If you are using CrmServiceClient.OrganizationServiceProxy in your code, you are using WS-Trust.
Check the following:
- If your client applications using Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy:
Replace all occurrences of the type OrganizationServiceProxy with the IOrganizationService interface
2. using CrmServiceClient with the “Office365” authentication type:
Switch over to using an OAuth based connection string, Note that LoginPrompt can be set to “never” to simulate the way that the Office 365 behavior worked. Please note that the App ID and Redirect URI should be created in AAD in your tenant.
Few points to note before we conclude:
- An update to Microsoft.CrmSdk.XrmTooling.CoreAssembly is available for download through NuGet package that includes auto redirect support. This library will redirect an authentication type of Office365 to OAuth.
- If you were not able to login even using OAuth, check if MultiFactor Authentication/conditional access is enabled, if so consider registering application user (Service Principal) in Azure Active Directory.
CDS/CRM SDK – WS-Trust auth and OrganizationServiceProxy Deprecated
Use of Office365 authentication with the WS-Trust security protocol
If you still have issue, don’t hesitate to comment here…or reach to community using this link…