Introduction: In this blog we will see how audit logs in D365 can be fetched that can be used for reporting purposes. Auditing helps to track changes made to the data in D365. The System Auditing entity cannot be accessed. Actionable Audit is a App by Microsoft Labs in which the required audit logs can be stored in the actionable audit entity which can be used later on by fetching the records of that entity. This audit log can be helpful to create Dashboards in Power BI, create reports etc to get meaningful information from the data. Implementation: Step 1: First we enable the auditing for the organization(globally) in Settings > Auditing. Step 2: We then enable auditing for the required entities and fields. Step 3: Download the Actionable audit app from the AppSource. Step 4: After accepting the terms and condition is done, it will take some time to install the solution as shown in the notification below. Step 5: In the plug-in registration tool we can see the assembly MicrosoftLabs.ActionableAudit is present. Step 6: Out of the box some steps are already registered as seen below Note: Only if the field is enabled for auditing the logs will be stored in Actionable Audit entity. Step 7: If required, the out of the box plugin steps can also be unregistered. And we can also add custom entities to the list. The pre-image and post-images also must be registered for different message which is shown in the user guide in the AppSource. Step 8: After the logs are created they are stored in Actionable audit entity as shown in the below example. Hope this helped!

Introduction: In this blog article, we will be showing how use fetch XML to retrieve multiple records with the new Web API in Dynamics 365 version 9.0 Implementation: Step 1: The retrieveMultipleRecords() method retrieves a collection of entity records. The basic syntax is as follows: Xrm.WebApi.retrieveMultipleRecords(entityLogicalName,options,maxPageSize).then(successCallback, errorCallback); Here the options parameter refers to the query that will decide the data which has to be retrieved from the system. We will be using the fetchXml attribute  to specify a FetchXML query  to retrieve contacts of a specific account. The maxPageSize indicates number of records to be returned per page. If this is not specified the default value is 5000. In this example we have not specified the maxPageSize. Step 2:  First we write the code and upload it as a JavaScript web resource. Code var scripting = { retrieveMultipleContacts(executioncontext) { debugger; var formContext = executioncontext.getFormContext(); var accountId = formContext.data.entity.getId(); var fetchXml = “<fetch version=’1.0′ output-format=’xml-platform’ mapping=’logical’ distinct=’false’><entity name=’contact’ ><attribute name=’fullname’ /><attribute name=’telephone1′ /><attribute name=’contactid’ /><order attribute=’fullname’ descending=’false’ /><filter type=’and’><condition attribute=’parentcustomerid’ operator=’eq’ uitype=’account’ value ='” + accountId + “‘ /></filter></entity ></fetch > “; Xrm.WebApi.retrieveMultipleRecords(“contact”, “fetchXml= ” + fetchXml).then( function success(result) { for (var i = 0; i < result.entities.length; i++) { console.log(result.entities[i]); } }, function (error) { console.log(error.message); } ); } }; Here we take the execution context as the input parameter and we get the form context using the getFormContext() method. This method returns a reference to the form or an item on the form. Using the formContext we get get the account id which is used to fetch the contacts of that specific account. Step 3: On the account form, in  the form properties we set the Event to OnSave as shown below. Step 4: In the handler properties we set the function name, in our case it is scripting.retrieveMultipleContacts. And it is important to check the “Pass execution context as the first parameter” checkbox as shown below. Step 5: We see that the account A. Datum Corporation (sample) has two contacts. Step 6:  The script runs when the form is saved and while debugging we can see in the console, two contacts are returned in the results. We get the the attributes that were present in the FetchXML query. Hope this article was helpful!

Introduction: In this blog we will be discussing about System user in D365. Description: System Users are built in users in D365. Some important points that need to be kept in mind are as follows: The Mailboxes of the System user cannot be setup hence emails can’t be sent and received. If a plugin is run with the System user context then it bypasses all the security rules. No one can log in to the system as the System User. The System user is in the base business unit. There might be situations when we not only want the plugin to update records that can be viewed by us but there is a need to update the other records to which we don’t have access to, in this situation we can run the plugin with the System User context. A plugin can call other plugin/workflows hence if a plugin is run in the context of System User then all the other plugins that are run because of the parent plugin will also be run in the same context. Implementation: Step 1: By default, in D365 the System User can’t be seen in the users’  section, as shown in the below two views. On Searching in the Disabled Users also it doesn’t show the System User. The owner of the record can’t be changed to System Owner from the lookup field as System User does not show up. Step 2: There might be situations when we might need to perform checks on the record to know if the owner is System User or not to carry out some operations. If there are no records in D365 with the owner as System User then it’s a problem. One way of creating a record with System owner is by using plugins to create a record and run the Plugin in the System users context as shown below. Step 3: After that is done as shown in the below image the owner is set as System. Now we can perform our business logic as we have a record with the SYSTEM as the owner. Step 4: Now if we click on the Owner we go to the record which is read only and see the following details as shown below. Step 5: We can’t modify any details of this user. If we try to add a security role to this user we get the following error message as shown below.    

Introduction: In this blog, we will be demonstrating how to use JavaScript to check user security roles. This is applicable in organization where, there are users with multiple security roles. And only users with a specific role assigned to them should be allowed to carry on certain tasks. Scenario: There is an organization with two users,”User A” is assigned a custom role and “User B” is not assigned a custom role. Only “User A” should be able to Save the form as he/she has the custom role. Implementation: Step 1: Create two users “User A” and “User B”. Step 2:   Create a custom security role “CustomRoleA”. “User A” has the following security roles: Salesperson Sales App Access CustomRoleA “User B” has the following security roles: Salesperson Sales App Access Step 3: Now we write a JavaScript code to check the logged in users security roles and accordingly allow only that user to save the record who has the “CustomRoleA” security role. If a user without that security role tries to save the a newly created record, an error notification is shown and record is not saved. Step 4: Save this as a new JavaScript web resource in Dynamics 365 and we will make this code run on the “Contact” form which will be triggered on the form onSave event. Step 5: Now when “User B” makes a new record and tries to save it the following error message is shown. The record can’t be saved. The search results as shown in the below image states that there is no such record. Step 6:  When “User A” tries to make a new contact and save, the permission is granted to save the record and in the search the record is shown as shown in the below two images. Conclusion: By checking the security roles different functionalities can be restricted for any user like show/hide fields or buttons.

Introduction: In this blog, I will be giving an overview about access teams and a quick demonstration of the same. Brief Description : Access teams provides a way to share records between different functional teams without having to change or update the base security rule in Security roles. Access teams does not mean ownership of the record. The record is only shared so that other users can work on it. Scenario: There are two sales teams “Sales India” and “Sales US” in different business units.The users of both the teams can read the whole organizations data but can write/edit data to only those users data who are in the same business unit.Here if one team member of “Sales US” wants to write/edit a record of “Sales India” it is not possible. This is where access teams comes in the picture. Some users from “Sales US” can be given access to write/edit records of “Sales India” Steps: Step 1: There are two business units “Sales India”  and “Sales US” Step 2: Tom is a part of “Sales India Team” and Harry is a part of  “Sales US Team”. Step 3: Assigned both the users a custom role in which they can do the following as shown below: Read account records of the whole organization Create records at user level Write/edit records at business unit level Step 4: Now to enable access team we must navigate to entity for which access teams needs to be enabled as shown in figure below Here we go to Accounts entity and enable Access Teams then to save the changes made publish all the customization. Step 5: To use access teams we first create an access team template by navigating to Setting > Security > Access Team Templates Step 6: Here create a new template with an appropriate name and select the Access Rights and the Entity as shown in the figure below. Note:The entities field on which Acess Teams are enabled only those entities will be shown in the Entity field dropdown. By adding users, you are granting them the access rights to that record that are defined within the access team template, even if their base security role does NOT grant them those rights. Note, the access rights are ONLY being granted for that specific record. Step 7: Now we add a Sub grid on the Accounts main form so that the users can be added to the access team on the fly. Here in the Team Template field select the template made for the access team. After setting up the subgrid Save and Publish all the Customizations. Step 8: Harry is the owner of two records(Crook Motor Company & Lamborghini) as shown below. Tom is the owner of one record(Tata Motors) as shown below Step 9: Harry can view every record in the organization but cannot write/edit. As seen below harry can only read record created by Tom. Step 10: Now as harry wants to write/edit this particular record, the admin has to add him in the access team sub-grid to give him access to write to this record. Step 11: Now Harry can write/edit to that particular record as shown below. Conclusion: Using this technique we can easily make different user access teams and assign specific records to work on without having to deal with their base security roles.