The main issue that is encountered by many organizations relates to the retention policy of audit logs. Until this new changes, there was no retention policy for auditing, and auditing would be kept forever unless manually deleted by the system administrator.

With the new changes, administrators can not select a retention period, so that the audit records will be deleted automatically once that retention period is over. The available options for retentions vary from 30 days to 7 years (30 days, 90 days, 180 days, 1 year, 2 years or seven years). There are also additional options for setting a custom retention period in days or set a forever retention period. The screenshot below shows the default setting prior to making changes to the auditing retention.

The following screenshot shows the available options that are available for selection:

When selecting the Custom retention, the screenshot below shows the option to select a custom retention period and enter the number of days that you want to save your audit logs.

This is a great option when trying to save your log capacity, an issue that I had in the past that required having to go into each environment every 3 months and removing the latest audit log file.

If your tenant is managed by your own Customer Manager Key (CMK/BYOK), this feature does not seem to be available at this time.

The post Audit Retention enhancements in Power Platform Admin Center appeared first on Aric Levin's Digital Transformation Blog.

Some of the main changes that were made to the read-only grid, both within the View page and subgrid were made in order to be in compliance with the Microsoft Accessibility Standard. Due to this some great new features have been added, but also might have caused some features to stop working as expected. We will review these below.

First let’s take a look at the actual grid control. If you are looking at the grid in a Wave 2 Pre-GA instance vs a GA instance, there might be some differences between them.

Read-Only Grid in 2021 Release Wave 1 UCI

Read-Only Grid in 2021 Release Wave 2 Prior to GA

Read-Only Grid in 2021 Release Wave 2 in GA

First there are some performance improvements to the grid as well as the ability for the remember the grid view settings across the session.

Next the new grid control provides the ability to change the width/resize of the columns directly in the view. Simply move your cursor between two columns and you will be able to resize the columns. A sample is shown below:

Next, there is also the ability to reorder the columns in the view. You will notice that next to the Search there is a new icon called column options. Clicking on this icon will display all of the columns in the grid in a pane on the right hand side, and allow us to change the order of the columns using drag and drop functionality.

We also have the ability to add new columns to the view, by clicking on the Add columns button in the column options pane. Clicking the button will display a list of all available columns in the table that we are viewing and simply clicking on the column name will add the column to the list of columns so that we can add a column and change the order. We also have the ability to add columns from related tables in this view as well.

Once you add the columns and apply, you will see the new column in the view, but also you will notice an asterisk next to the view name, specifying that this is not the original view. If you want to save the new changes that you made to the view as a new view, you can do this by clicking on the Create View button, and select the Save as new view option (as show in the image below)

One of the issues that you should be aware of, is that if you added columns and wanted to revert back to the original state, do not use the Reset to default option. That will remove the column from the Column Options, but will not remove it from the grid, and you will not be able to remove it (unless you do a Hard Refresh of the page). If you want to remove a column that you added you will need to go to the column options panel, select the three dots next to the column that you want to remove, and choose Remove from the list of options (as seen below).

Before closing this subject, there are a couple of known issues which Microsoft is addressing at the moment, and might be released a little after the GA of the product.

The first item, is that the ability to filter items by starting letter (See the first image from Wave 1) is no longer available. This has been reported to Microsoft, but a timeframe for this fix is not yet available, but the expectation is that this will be coming soon.

The second item, which might cause some frustration is the selection of multiple records. In Wave 1 (or previously), when wanting to select multiple records, you would need to have your mouse positioned in the cell of the check, and then select the rows that you wanted (shown below)

In Wave 2, there is a radio button in the cell. If you click on the radio button you can select multiple items, however if you click outside of the radio button, it will clear the previous selections, and only select that item that you clicked on. Hopefully this will be addressed soon as well, as it might be a little frustrating.

Additional posts related to the Dynamics 365 and Power Platform 2021 Release Wave 2 will be posted by following the link below:

Power Platform 2021 Wave 2 Release Posts

The post Power Platform 2021 Release Wave 2 Unified Interface Updates – Grid Enhancements appeared first on Aric Levin's Digital Transformation Blog.

Currently when adding values to a lookup control, there are certain capabilities that allow us to find the records that we are looking for. These capabilities include searching for a record by text and changing the view. We also have the ability to create a new record which will open up the quick create form if available.

The image below shows the current layout of the Lookup controls prior to Wave 2.

When you open a similar record in Wave 2, initially it seems like this behavior is the same, but you will notice that the Change View has been replaced by Advanced Lookup. See image below:

So, what is this mysterious Advanced Lookup? The Advanced Lookup will open up a dialog that will display the full view of all the fields that make up the Lookup view for the table that we are triggering. We still have the ability to search in this new popup window, change the view, and every time that the view is changed, we will see the full list of columns in the view (not like we are seeing in the lookup control itself). We are able to select the record that we want, click on Done and get it populated in the Lookup control.

If you click on the link of a particular it will open up that record on a dialog above, so that you can see additional data before selecting the actual record.

Earlier this year, Microsoft introduced polymorphics relationships or multi-table lookups. What this means is that we can have a single lookup control that will provide us the ability of having a data source of multiple tables and not just one (similar to activities, but not multiselect).

There are several ways to create Polymorphic Lookup controls, but probably the easiest way is to do it using the XrmToolBox Polymorphic Lookup Manager plugin. You select the solution and table, add the name of the lookup and then select the entity relationships that are required for this new control.

The image below shows this in XrmToolBox.

Once you have configured your settings, just click on the Create Polymorphic Lookup button, and this will create the new attribute for you. This process can take 15-30 seconds.

If you navigate back to your solution explorer, you will notice that the control is created, but it will not show that the control is a Polymorphic Lookup control, but just a lookup control, and in the related table area it will only show a single related table. Probably something that will be addressed in a later release. The image below shows how this looks in the maker portal.

Now that the control has been created we will go ahead and add it to the form. This is just like any other control that you add to the form. There is no special configuration that is required for this.

In the case below, I created 3 tables to store the manufacturer of a vehicle (Motorcycle Manufacturer, Car Manufacturer and Aircraft Manufacturer). Once I put the control on the form. And click on the search icon on the control, I will see the results from all of the related entities in a single search results, as shown below. You can filter this by record type, by clicking on the link next to Results from, which shows three types of records.

Finally, when we click on the Advanced Lookup link on the polymorphic lookup control, we will get an additional area on the left hand side of the dialog, where we can select which table we want to filter and select the record from. Switching for one option to another will show us different results, but only a single record can be selected. The Add new option on the top right, will now have a drop down next to it, so that if we need to add a new record, we can add the record to the correct table that we want. The image below shows the Advanced Lookup dialog for the Polymorphic Lookup control.

Additional posts related to the Dynamics 365 and Power Platform 2021 Release Wave 2 will be posted by following the link below:

Power Platform 2021 Wave 2 Release Posts

The post Power Platform 2021 Release Wave 2 Unified Interface Updates – Advanced Lookup appeared first on Aric Levin's Digital Transformation Blog.

Editing multiple records at the same time has been a feature used in Microsoft Dynamics/Power Apps for as long as I can remember.

You would basically have to select multiple records click on the Edit button, and this would display a pop up and empty form, where you can make changes to the records and it would update those changes across the multiple records. The screenshot below shows the behavior prior to Wave 2.

One of the biggest issues that I used to have with this feature is that some fields are not always available on all forms, and the form that was displayed for the multi record editing did not always have those fields that I was looking for.

Seems like this has been addressed with the new Edit multiple rows feature that is being released as part of Wave 2. The screenshot below shows the Edit Multiple Rows that is part of Wave 2.

As you can see, a form is being displayed as a pane on the right hand side, and it looks just like a form that I would be opening if I wanted to created or edit the record. We have a display of the number of records that we are editing, the selected form and the tabs that I can navigate through. So how does this resolve the issue that I mentioned above?

The ability to change the forms, allows me to continue the Multi Row editing capabilities on a different form. If I have an Admin form containing all the required fields, I would be able to make the changes in that form, and it would apply to all the required fields.

The screenshot below, comes from the Microsoft Docs page showing the different parts that make up the Multi Row editing screen

The legend for the above image is as follows:

1. Shows the number of rows that you’re editing.
2. Shows the form title.
3. Select the chevron icon to switch from the default form to another form.
4. Select a tab to edit the columns on the form. The header column is always listed on the last tab.
5. If you changed the data for a required column, it needs to contain data otherwise you won’t be able to save your changes.
6. Shows the form details that can be edited.
7. Save or cancel your changes. Saved changes are saved for all selected rows.

Additional posts related to the Dynamics 365 and Power Platform 2021 Release Wave 2 will be posted by following the link below:

Power Platform 2021 Wave 2 Release Posts

The post Power Platform 2021 Release Wave 2 Unified Interface Updates – Edit multiple rows appeared first on Aric Levin's Digital Transformation Blog.

The challenge was not so easy. We are still not fully managed in all the environments, but as a stepping stone, all environments with the exception of production are already managed and as we are working on a large migration, the final deployment is only a few months away.

After reading and watching the Microsoft blog and video on what they had to go through with Success Hub, I felt that my endeavor was not as complex. You can read the blog and see the video by clicking on the links below:

https://powerapps.microsoft.com/en-us/blog/how-a-microsoft-team-transitioned-from-unmanaged-to-managed-power-platform-solutions/

https://docs.microsoft.com/en-us/power-platform/alm/move-from-unmanaged-managed-alm

https://www.youtube.com/watch?v=3Uu5C9zkIjo (PowerCAT Live)

As with many of these special projects, there are sometimes blockers that you need to address with the functionality of your application. Ours was related to command bar customizations not being deployed from our development environment (unmanaged) to our QA environment (managed).
My apologies in advance for all the bluring, but this was the only way to get the screenshots.

The screenshots below show the difference between the functionality in our development and qa environments after the re-deployment of our managed solution to qa.

As we saw this difference we wanted to go ahead and compare the Ribbon customization differences between the environments, and just as the UX had the differences, so did the commands themselves. It seemed like there was an enable rule missing in the qa environment that was not missing in the development environment. This was done of course using the Command Checker utility that can be invoked by adding the ribbondebug=true key/value to your query string
(ex: https://dev.crm.dynamics.com/main.aspx?appid=1234&forceUCI=1&ribbondebug=true&pagetype=entityrecord&etn=account&id=1234)

See image below for comparison

As with many of the know issues with managed solutions and customizations that do not get overwritten (we experienced this with cloud flows as well), the issue is usually when there is an Unmanaged Layer on top of a Managed layer, and then the customizations do not get overwritten.

When we clicked on the Command Checker, and selected the command that was not performing as expected (1), chose Command Properties (2) we can see the rules that were supposed to be enabled in this environment.

The rule that we were expected was not visible. Clicking on the View command definitions solution layers (3) will display any layers that are being used for the command that we are looking at. The image below shows you the results that we saw when clicking on the link.

In the Command checker solution layers pane, you can also select two layers and compare them to see the CommandDefinition code of the RibbonDiffXml.

Once we saw that there was an Unmanaged Layer (Active Layer) on top of our managed solution layer, the solution was pretty easy, but we required to do this in a few places.

The first thing is we created a new solution in our qa environment. We called this solution Command Bar Fixes, and added the table were we had to fix the customizations. When we added the table, we only selected Include table metadata from the options, and did not select any components. Image below:

Our solution contained a single table with only the table metadata as shown below.

We then Export the solution. There should not really be a need to publish customizations before (as we have previously seen the results in the Command Checker), but if you are accustomed to this practice, do not change your ways…

Once we export the solution, we navigate to our downloads folder and extract the Command Bar Fixes solution. We open the newly created folder, and within the folder we open the customizations.xml file using an editor of our choice. The customizations.xml file should contain the table specific information as well as the Ribbon Diff Xml and other information about the table. The image below shows this file before we fix it.

I collapsed the RibbonDiffXml containing all the commands, as these are not really relevant. We will go ahead and remove all of the inner Xml of the RibbonDiffXml section, and only leave the <RibbonDiffXml /> tag so that it looks like the image below.

We then save the changes, and select all the files that are in the extracted folder. Right click and select Send To, and Compressed Folder. We will reimport the newly created zip file.

Navigate back to the Maker portal, click on solutions and select import. In the browse panel, select the zip file that you just created containing the customizations.xml, solutions.xml and [Content_Types].xml.

Import the file and publish your changes. After this navigate back to the table were you experienced the issue and validate that the active layer is now gone and you only have the managed layer.

Hope this was helpful. It was painful for us to get the resolution, so maybe it will help some of you.

The post Removing your Command Bar Unmanaged Active Layer in Model Driven Apps appeared first on Aric Levin's Digital Transformation Blog.

The screenshot below shows the error message that we were getting.

After further investigation and with the help of our PFE, we found out that the issue was related to a change that Apple incorporated on devices with iOS 14 installed. This change was not allowing cross-website tracking which was enabled in previous versions of iOS.

To enable this, and allow embedded Canvas Apps to run on iOS 14 devices, we needed to change the setting below.

Once this change is done, navigate back to the Embedded Canvas App in your Dynamics 365 App or Power App and you should be able to see that you Canvas app is loading.

A special thanks to Aaron Richards, our Microsoft PFE for helping troubleshoot this issue.

The post Fix Embedded Canvas App error in iOS 14 devices appeared first on Aric Levin's Digital Transformation Blog.

To tell you the truth, I have not really worked with Virtual Entities, ever since it was released, and I would have a lot of reasons to actually use them, it just never seemed the right time. In the recent release, I actually did my own little PoC to determine the complexity, and if it was always that simple, probably something to regret.

Let’s jump into it. Virtual tables (or Virtual entities) have been available for quite some time now, but only for read access. Now with the addition for Create, Update and Delete, this gives us for access to integrating between our Dataverse environment and a publicly available SQL Server (or other platform). In today’s post we will show how to go through the process of creating the SQL Server table, creating the plugin, data provider, data source and finally the virtual table an connecting all the pieces together.

All of the source code in this post is shown in images, but will be available via the Github Link at the bottom of the post.

Let’s start with the database. In this case I used an Azure SQL database, and created a table called Service Request. The script for creating the table is shown below.

Next we create a Plugin Project in Visual Studio. You will need to install the following packages in your project in order to get access to all of the required resources (per Microsoft documentation):

• Microsoft.CrmSdk.CoreAssemblies
• Microsoft.CrmSdk.Data
• Microsoft.CrmSdk.Deployment
• Microsoft.CrmSdk.Workflow
• Microsoft.CrmSdk.XrmTooling.CoreAssembly
• Microsoft.IdentityModel.Clients.ActiveDirectory
• Microsoft.Rest.ClientRuntime
• Newtonsoft.Json

Within the plugin we will create 6 Classes. The first is a static class containing the Connection code, and the other classes are each for a message (Create, Retrieve, RetrieveMultiple, Update, Delete). You can create them as a single file or in multiple files. For the demonstration they are all created in separate files.

The following using statements have been added to all files, although not all is required for all classes.

Let’s start with the Connection class. We use the SqlConnectionStringBuilder class to generate the Connection string and return it to the rest of the classes that will consume it. This is shown in the image below.

Next, let’s look at the CRUD classes. All of the classes implement the IPlugin interface and call the Execute function of that Interface. In each of the class based on the required functionality we retrieve the Execution Context in order to read data from the Dataverse environment, and then synchronize between our Dataverse environment and our Azure SQL Server. The screenshots below show the code for each of these.

Create Class:

Retrieve Class:

Retrieve Multiple Class:

Update Class:

Delete Class:

Once the code for the Plugin is completed we will go ahead and register the plugin via the Plugin Registration Tool. Before registering the plugin, make sure that you have the latest version of the Plugin Registration Tool that provides support for CRUD operations in virtual tables. At the time of writing this post, the required version was 9.1.0.24. You can find the download link below:

https://www.nuget.org/packages/Microsoft.CrmSdk.XrmTooling.PluginRegistrationTool

Now let’s go ahead and register the Plugin. This should include all of the five messages above. Once the Plugin is registered, we go ahead and Register a new Data Provider (using the Plugin Registration Tool).

Click on the Register button, and select Register New Data Provider (Ctrl + P).

When selecting the Data Source Entity for the first time, choose the Create New from the drop down. It is important to select the solution that contains the publisher that has the prefix that you want to use, or you will have to modify you code for something else.

Once we are done with creating the data provider in the Plugin Registration Tool, we can go ahead and start setting up the Virtual Table in our Dataverse environment. This functionality is not available yet in the Maker Portal, so we will have to do this in the Classic interface (Advanced Settings).

Navigate to Settings and Administration, and select the Virtual Entity Data Sources, and click on the New button. A popup will appear with a drop down to select a Data Provider as shown in the image below.

Select the name of the Data Provider that you selected, and click on the OK button. Then you will be able to provide a name for the Data Source.

Click on Settings again and select Solutions. Select the name of the solution where you want to create the fields for this table. Check the Virtual Entity option, and select the Data Source that you just created. Enter a Display Name, Plural Name and Name for the entity. You will notice that there are two additional Names which are the External Name and the External Collection Name. For the External Name, you should enter the name of the Source table. The External Collections name can contain the same values as the Plural table name.

Once you have finished creating the table, go ahead and create all of the columns that you are going to use to view or update within the Virtual Entity. Only add columns that you want to either read from your Azure SQL table or that you want to write back. Any columns that are for management only are not really required. The image below show the columns that were created for our test:

Next, we need to add this entity to our Model Driven App, so that we can test this out. Select an existing MDA or create a new one and add the entity to it.

Finally go ahead and test the results.

The animated screenshot above shows adding, reading and updating entity fields using CRUD operations.

You can click on the link below to get access to the Source Code:
https://github.com/ariclevin/VirtualTables

The post CRUD Support for Virtual Tables appeared first on Aric Levin's Digital Transformation Blog.

This seems to be straight forward. The security is handled within our Dataverse environment, and users that do not have Read privilege would just not see the data, and I could control the look and feel within the Canvas app so that the result looks good to either user.

The screenshots below show the sample of how this should look like to users with the privilege and without.

Full Privileged User:

Limited Privilege User (with No Access to Project Members):

This looks good, but unfortunately this is not the end of the post. Actually, what ended up happening is that when I opened up the form using the less privileged account, I would see the following error:

The error makes sense, you don’t have privilege to see these records. I know this, but why are you displaying the error message.

So further analysis determined that this is the way that I load up the records into my Canvas App. I can load the records using the Data Source directly, in my case Projects and Project Members, or we can load the records into a local collection, and then manipulate the data if needed and display the data to the user as ProjectsCollection and ProjectMembersCollection. The source code below, shows the option of using a Collection.

Since we needed to manipulate the data, the second option made more sense, but now this error. To resolve this issue we first enabled Formula-level error management in the Settings area of the app.

Next we need to add code to handle the error message, so that we display something a little cleaner or maybe not at all.

We modified the code to include the IfError function and show a notification that the user does not have privileges to see the data.

We were also able to hide the completely from the user by setting the length of display to 1 millisecond.

So, the verdict is if you are using Collections that need to retrieve data from a data source, and your users might not have privileges to them, make sure that you add error handling code to that, because you Canvas app will not handle this automatically.

Adding a shoutout to Hardit Bhatia on his blog article on custom errors in Power Apps:
How to create custom errors in Power Apps! | Hardit Bhatia: The Power Addict

The post Handling Missing Dataverse Privileges in Canvas App appeared first on Aric Levin's Digital Transformation Blog.

I will go over just some of the items that made it to the Power Apps Model-Driven Apos. Future posts will discuss Dynamics 365 enhancements, and the other Power Platform Apps. I had to add the picture that was part of the release notes.

In-app notifications for Model-driven apps

In-app notifications are shown to users as a notification toast or within the notification

center. Notifications are directed to a specific user and can be sent through external systems,

Power Automate, or from within the system

Multi-line text controls expand in Quick View forms

Prior to this release, Multi-line text controls that were added to Quick views had to be clicked on and scrolled through in order to see the entire content. In this release, users will no longer have to follow that logic, and the fields will automatically expand to show the full content when a Quick View form is loaded on the page.

Duplicate detection Unified Interface experience

The new experience for duplicate detection was introduced in the previous release, but required to be enabled by the admins. In the upcoming release, this will be the default experience.

The updated experience dialog is integrated seamlessly with merging records to help you manage data integrity when duplicate records are found. With this new duplicate detection experience you can quickly find and manage records with easier access to merge the duplicates and keep the record you want. When you merge a record, any related or child records are also merged.

Merging records Unified Interface experience

The new experience for merging records was introduced in the previous release, but required to be enabled by the admins. In the upcoming release, this will be the default experience. Not much has changed in the functionality with the exception of the design, and the ability to call merge functionality when duplicate records are detected

I will publish more as I go on reading about enhancements to Dynamics 365 and the Power Platform.

The post 2021 release wave 1 plan – First Look – Power Apps Model-Driven Apps appeared first on Aric Levin's Digital Transformation Blog.

There are however other alternatives, that might make more sense, especially if you want to minimize the amount of code and plugins that are accessible within the system.

The solution is simple. We create a Webhook and add to it the corresponding step and Pre-Image, and upon execution it will be triggering a Cloud flow where we can use the values from the Input Parameters and the Pre-Entity Image.

Let’s go ahead and see how we implement this. The first step is to create a Cloud flow, and set the trigger to When a HTTP request is received.

The HTTP POST URL is not available until the flow is saved, so enter the request Body JSON Schema. You will need to enter an action to Save the Flow, so you can enter an Initialize Variable, which we will use later set a name for the flow and Save the record. Once the record is saved, the HTTP POST URL will be filled in and you will be able to configure the Webhook. Copy the HTTP POST URL and paste it in NotePad or other text editor. The result should be similar to what you see below:

https://prod-XXX.westus.logic.azure.com:443/workflows/41e03b6243cc47273a71f827fb3bd29b/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=e5138Klq7cOcbG1RJ2bXA42et4vFM0-kZ3k8jyK7Txs

Add new lines between the url and the query string parameters and remove the separators so that it looks like this:

https://prod-XXX.westus.logic.azure.com:443/workflows/41e03b6243cc47273a71f827fb3bd29b/triggers/manual/paths/invoke

api-version=2016-06-01

sp=%2Ftriggers%2Fmanual%2Frun

sv=1.0

sig=e5138Klq7cOcbG1RJ2bXA42et4vFM0-kZ3k8jyK7Txs

Replace all the %2F encodings with the corresponding character (/). This will change that line to look like this: sp=/triggers/manual/run

Now, let’s go and open the Plugin Registration Tool, and click on the Register drop down and select Register New Web Hook, or CTRL+W for short.

This will open the Register New Web Hook dialog when we will enter the HTTP URL and the different parameters that we specified above as shown in the screenshot below.

Now that we have registered the Web Hook, you should be able to see the new Web Hook in the list of Registered Plugins. Select the Web Hook, and select Register New Step (either by Right Clicking on the Web Hook and selecting Register New Step or from the top tab menu).

Just as you would perform this step registration process for a plugin, do the same for the Web Hook. Select the Message, Primary Entity and Filtering Attributes as shown in the image below. Of course you should customize this for your own message..

Since we want to get the value before the change and after the change, we need to register a new image for the step of type Pre Image, as shown in the screenshot below. Add the name and entity alias, and specify the parameters that you want for you Pre Image.

Now that we are done with the configuration within the Plugin Registration Tool, let’s take a look at where this data will be stored. We created a new entity called Change Log that contains information about the entity and the record that was modified, along with fields to store the values before and after the change.

Next, let’s go back the flow that we created. We will start by initializing a few variables that will be used to store some of the values, and then retrieve the values from the HTTP Post method.

It is a good idea to run the flow once so that you can review the Outputs of the When a HTTP request is received trigger, and that will help you with constructing the expressions needed for the different steps.

The variables are shown in the image below. The Pre and Post variables will be added later, while the Entity Id, Entity Name and User Id can be filled out during the initialization as follows:

• triggerBody()?[‘PrimaryEntityId’]
• triggerBody()?[‘PrimaryEntityName’]
• triggerBody()?[‘UserId’]

Since getting the values from the Input Parameters and the PreImage is a little more complex, I used two compose actions for these, and set the Inputs to as follows:

• triggerBody()?[‘InputParameters’][0][‘value’][‘Attributes’]
• triggerBody()?[‘PreEntityImages’][0][‘value’][‘Attributes’]

The final step before storing the record is doing an Apply to each of the Input parameters and check the value corresponding to the attribute that was changed. We run this for both the PreEntity image results and the Input Parameter results and have a condition to check for the Input Parameter.

The Condition logic expression is: items(‘Apply_to_each_PreEntity_Image’)?[‘key’], and the Set Variable Pre contains the following expression: items(‘Apply_to_each_PreEntity_Image’)?[‘value’]

The same applies to the other apply to each action. Once we have retrieved all the information that we need, the change log record will be created. 

The results will look like this:

The post No-Code Solution for custom Change Log using Web Hooks and Cloud Flows appeared first on Aric Levin's Digital Transformation Blog.