In the second part of the installation of configuration of Azure Logic Apps with the On-Premise Data Gateway, we will review the requirements that are need inside of the Azure Portal. This will cover the creation of the Data Gateway resource, the Logic app and the creation of the Trigger and Action inside of the Logic App designer.
I recently had a requirement to configure Logic Apps for use with the Azure On-Premise Data Gateway and connection to an Oracle On-Premise database. Since I did not have access to the Oracle database at that point, I decided to try this out with an On-Premise SQL Server database as the logic should have been similar. I downloaded the Azure On-Premise Data Gateway and installed it on the server, and the configured the Azure environment to connect to the server and post data back to Dynamics 365.
We recently had a requirement that users wanted to hide the Delete icon on the subgrid to prevent users from deleting records. Of course it is possible to remove the Delete privilege on the entity in Security Roles, but the requirement was different. When the status of the parent record was Active, the Delete operation should be allowed, however when the parent record was Inactive, the Delete operation should not be allowed.
While working on a project, I recently encountered a strange behavior in Dynamics 365. I am not sure if this is a bug (or feature), but something that we should be really careful about. One of the entities that we were working on, was created without following the organizational guidelines and had to be recreated. In this particular scenario it is not really a big deal because the project is still in early stages of implementation so changes and cleanup occur on a regular basis.
In a few of my recent implementation I had the requirement of making modifications to many child records. Some of these processes required the use of an external SSIS package that executed a console application and ran on a schedule, but more recently I had a requirement to simply deactivate multiple child records. This of course can also be done using cascading rules, but it’s a little more complicated once you involve custom filtering.
I have encountered many engagements in which the client needed to migrate data from other systems which had users that were not longer within the organization, and those users did not require access to Dynamics 365, but the client wanted to keep track of who the original owners or users that created the records were.
In this third post of the series, we will review the changes between the properties and methods of the control based on the getControls Collection or the Xrm.Page.getControl method. The tables below will show the base methods of the control, as well as specific method for specific control types.
With the release of Microsoft Dynamics 365 Customer Engagement (July 2017 Update), Microsoft has finally included new Email functionality in the Unified User Interface. This includes the new email designer, with many enhancements, preview for multiple devices, and well as email tracking. This post will show some of these features and capabilities within this post.
Microsoft is currently in the final phase of preparation for the Customer Driven roll-out, which will allow Customers to schedule the update of an instance to Dynamics 365 v9.0. The target date is set for January 2018, with a processing window of the scheduled updates to begin in February 2018.
With the release of Dynamics 365 July 2017 Update, Web Api functionality can be performed by calling the functions and properties of the Xrm.WebApi class. The WebApi methods are available for both online and offline access (with offline access being available to mobile clients working offline). The base methods that are available for using the Xrm.WebApi include the following: createRecord, deleteRecord, retrieveRecords, retrieveMultipleRecords, updateRecord, execute and executeMultiple. The following blog post will provide a short description of each and code sample for each one. The execute and execute multiple will be shown in part 2 of this blog article
