By default, when the 2022 Wave 1 is enabled, the grid that will show up under the Controls tab for the Entity that you want to enable the grid is the Read only grid (Default). This is the grid that was enabled as part of the previous Wave with a few enhancements. The image below shows you the look and feel of the grid that was available as part of 2021 Wave 2.

Once your instance has been upgraded, you will be able to see some changes to your grid control. Theses changes include the labels next to the buttons for Edit columns and Edit filters, the grid title bar design is slightly different, the row selectors have been slightly modified, and at the footer of the screen you will see not only the number of records, but will have the pager visible (regardless of the number of records on the screen). The screenshot below shows the 2022 Wave 1 Read Only Grid as it is out of the box after the upgrade.

In order to get some of the additional functionality in the grid, we will need to use the Power Apps Grid instead of the default Read Only Grid. The Power Apps grid contains some additional properties call Jump bar, Reflow behavior and Allow filtering, which we will discuss in a bit, but first, let’s enable the Grid.

As parity is not yet available between the modern solution designer and the classic designer, we still have to configure PCF controls from within classic interface. In order to do this following the steps below. This will be demonstrated on the Account table, but can be done for any of the entities.

• Navigate to a solution containing the and click on the Accounts table, and click on Accounts
• On the command bar click on Switch to Classic
• Once classic window/tab has opened for the Account entity, click on Controls
• You should see there the Read Only grid control.
• Click on the Add Control link under the list of existing controls
• In the Add Control window, look for Power App Grid, and click on the Add button
• In the Controls section you will now see both PCF controls, the Read Only grid and the Power Apps grid.
• Make your Power Apps grid the selected one by selecting the radio buttons under Web, Phone or Tablet

Before we go back to the Accounts view, let’s look again at the properties that are available to be modified for the PCF control.

Jump bar: Jump bar is disabled by default and display at the bottom of the grid the selectors to allow to filter the results by any alphabetical letter, but numbers or seeing all the results. This has been available for a long time, but now can be selected whether it should be visible or not.

Reflow behavior: The reflow behavior determines how we want to control the flow of the grid/view. There are three available options for selection in Reflow:

• Grid Only – will show the rows in a grid view regardless of the width of the screen
  
• List Only – will show the rows in a grid as a list regardless of the width of the screen
  
• Reflow – will show the rows in a grid view when space is available, and when the width gets decreased so that it is not properly viewable, it will automatically change to a list view.

Allow filtering: This option sets weather filters are available on the individual columns or not.

Finally, there are also a few settings that are set on the environment scale which are available on your Environment -> Settings -> Features. In the Grids and views section, you will notice that you can set if you want to use the Modern Grid experience, as well as whether the Edit columns button and the Edit filters button are visible on the views.

The post 2022 Wave 1 Release Power Apps Read Only Grid appeared first on Aric Levin's Digital Transformation Blog.

In this post, I will walk through adding the control to the form, saving the record and seeing how we can use some basic plugin logic and configuration to write that data in related entities.

The control is not linked to any of the related entities that you are adding, but only stores a JSON string value to the attribute.

Let’s first go ahead and find the control. If you navigate to you Default solution, and filter by custom controls and do a search for Lookup, you will find the following controls:

Next we are going to need to create an attribute (column) in the Maker Portal to host the control. Since the data in the control that is being used is in JSON format, you need to consider the size of the column that you are creating. The format that is being stored in the control contains the Id, the name and the Entity Type Name.

The image below contains two fields that are being used for this control. The first will host the PCF control, while the second will host just the text values of the control in order to be displayed in a view for the users.

For the purpose of the demo the Contacts column is set to a length of 1000, and the Contacts Value is set to a length of 200.

Now let’s go ahead and add the control to the form. The control is not available in the maker portal, so we will have to use the Classic/Legacy portal to add the control to the form. In the image below we see that the control has been added to the form. We will now go to the properties of the control, and select the Controls tab.

In the controls tab, we will click on the link to Add Control, and then select the control that is called MultiselectLookupControl. We then set the Web, Phone and Tablet options to use the new control instead of the Text Box (default) control.

There are two properties that need to be set in order to use the control. Those are the entity name, which is called entityName_Display_Key and the default view id, called defaultViewId_Display_Key, which can be retrieved from the Home Page views of the Contact table or from the Maker Portal when editing a view. These are displayed as part of the Urls.

Now that we have added the control, we can test how the control works on the form. Note that we have not implemented any logic for what we want to do once the user adds values to the control.

The images below shows you how the control will look on the form once multiple values have been added, and the data that has been saved.

Now that we have seen the controls on the form, let’s start and building some of the logic that is associated with it. As this control that we are going to be using will be for a native many to many (N:N) relationship, we will need to provide some configuration data that will be stored in the plugin. Since you can have multiple controls on the form itself, the configuration will allow the plugin to loop through all the controls and process them accordingly.

The configuration information will store the column name of the control, the type of relationship (in this case only native, but in future posts I will show how to do the same for a manual relationship), and the relationship name. I also have the text attribute name if we want to use a separate attribute for storing the names only of the selected records (this is for display in views).

The configuration contains a JSON array with the following key/value pairs: Attribute Name, Text Attribute Name, Relationship Type and Relationship Name as shown below:

[{“_attributeName”:”crde5_contacts”,”_textAttributeName”:”crde5_contactvalues”,”_relationshipType”:”native”,”_relationshipName”:”crde5_accounts_contacts”}]

We will store that in the Unsecure Configuration or Secure Configuration of the Plugin Step. The image below shows you how this looks within the Plugin step, but this will have to wait till the plugin is complete. The highlighted items shows the required configuration.

Next, let’s go ahead and build the plugin. We add two files to the plugin.

The first files contains two classes which are used for the serialization/deserialization of the JSON string from the PCF control and the JSON string for the Unsecured configuration. The LookupObject class contains the id, name and entity name that are saved by the PCF control, as shown in the code below.

    [DataContract]
    public class LookupObject
    {
        [DataMember] 
        public string _id { get; set; }
        [DataMember] 
        public string _name { get; set; }
        [DataMember]
        public string _etn { get; set; }

        public LookupObject(string id, string name, string etn)
        {
            _id = id;
            _name = name;
            _etn = etn;
        }
    }

The second class, LookupAttribute, contains the information about each attribute that is configured for use by the plugin. We use the attribute name, text attribute name, relationship type and relationship name.

The attribute name is the name of the attribute of the PCF control field. The text attribute name is the attribute of the text only concatenation of the values from the pcf control in a separate text attribute. The relationship type will contain the value of native or manual based on the type of relationship, and the relationship name contains the name of the relationship that will be used for the Associate Requests. The code below shows the Lookup Attribute class that will be used for serialization.

    [DataContract]
    public class LookupAttribute
    {
        [DataMember] 
        public string _attributeName { get; set; }
        [DataMember]
        public string _textAttributeName { get; set; }
        [DataMember] 
        public string _relationshipType { get; set; }
        [DataMember] 
        public string _relationshipName { get; set; }

        public LookupAttribute(string attributeName, string textAttributeName, string relationshipType, string relationshipName)
        {
            _attributeName = attributeName;
            _textAttributeName = textAttributeName;
            _relationshipType = relationshipType;
            _relationshipName = relationshipName;

        }

    }

Next, let’s look at the plugin code. The plugin contains a single class (so far) that is used for the retrieval of the secure and unsecure configuration strings and for the execution of the plugin code.

In this case we will be using the unsecure configuration. The code below shows the code to get the secure and unsecure configuration and store them in variables.

        string _unsecureConfigData = string.Empty;
        string _secureConfigData = string.Empty;

        public MultiSelectLookupPostCreate(string unsecureConfig, string secureConfig)
        {
            if (!string.IsNullOrEmpty(secureConfig))
                _secureConfigData = secureConfig;

            if (!string.IsNullOrEmpty(unsecureConfig))
                _unsecureConfigData = unsecureConfig;            
        }

Next we will look at the code of the Execute function. The entire code will be shared in my github repo, so I will only be going through the relevant code.

First we will create a List of type LookupAttribute which will contain all of the different attributes that this code will need to run for. If there are multiple PCF controls, the same code can be run for all of them. The code below shows how to ready the configuration data from the JSON unsecured configuration string that was initialized previously.

List lookupAttributes;
using (MemoryStream stream = new MemoryStream(Encoding.Unicode.GetBytes(_unsecureConfigData)))
{
   DataContractJsonSerializer deserializer = new DataContractJsonSerializer(typeof(List));
   lookupAttributes = (List)deserializer.ReadObject(stream);
}

Next, we will loop through each of the controls, and within each of the controls we will get the JSON data of that control, serialize it.

foreach (LookupAttribute attribute in lookupAttributes)
{
   string controlData = target.GetAttributeValue<string>(attribute._attributeName);
   using (MemoryStream dataStream = new MemoryStream(Encoding.Unicode.GetBytes(controlData)))
   {
      DataContractJsonSerializer dataDeserializer = new DataContractJsonSerializer(typeof(List));
      List lookupObjects = (List)dataDeserializer.ReadObject(dataStream);
...
   }
}

We will loop through each of the selected values in the PCF and add them to the entity reference collection so that it can be associated. The code below shows the loop.

List<string> lookupObjectNames = new List<string>();
EntityReferenceCollection relatedReferences = new EntityReferenceCollection();

foreach (LookupObject lookupObject in lookupObjects)
{
   Guid lookupObjectId = new Guid(lookupObject._id);
   relatedReferences.Add(new EntityReference(lookupObject._etn, lookupObjectId));
                                        
   lookupObjectNames.Add(lookupObject._name);
}

Finally, now that we have the collection, we will execute the Associate Request to add all of the values to the native relationship:

AssociateRequest request = new AssociateRequest();
request.Target = target.ToEntityReference();
request.Relationship = new Relationship(attribute._relationshipName);
request.RelatedEntities = relatedReferences;
AssociateResponse response = (AssociateResponse)service.Execute(request);

We can then if necessary, update the created record with the text attribute of the name values of the PCF control, shown below.

Entity update = new Entity(target.LogicalName);
update.Id = target.Id;
update.Attributes[attribute._textAttributeName] = String.Join(",", lookupObjectNames);
service.Update(update);

This is basically it. In the next blog articles, I will demonstrate how to update existing controls as well as how to create and update 1:n relationship records. A video will be coming shortly to demonstrate this functionality.

You can find the code in the following my github repository below

https://github.com/ariclevin/PowerPlatform/tree/master/PCF/MultiSelectLookup

The post Using Microsoft Multiselect Lookup in your Model Driven Apps appeared first on Aric Levin's Digital Transformation Blog.

Converged apps allows us to converge a Model-Driven App and a Canvas App into a single app. This does not change the ability to create standalone Canvas Apps, but only the ability to have them available in a single app. The link below details the changes that were announced at the end of July

https://powerapps.microsoft.com/en-us/blog/custom-pages-for-converging-model-driven-apps-and-canvas-apps/

In the maker portal, when you navigate to your apps section, you will see the list of both Canvas and Model Driven Apps, and you can still create your apps from here.

Custom pages can be used within our model-driven apps anywhere where all pages are supported. This means the main area of the application, dialogs or the new app side pane. It allows the ability to have functionality that is not achievable using the standard features of model-driven apps, but can be achieved using canvas apps.

Custom pages can be opened from the site map for ease of access or from existing model-driven app logic using the Client Api. Custom pages can also open other custom pages or model-driven app pages. They give us the ability to author pages that are too complex to achieve within the existing model pages.

When we create a new app we can now easily add custom pages and take advantage of Canvas Authoring.

There are a few ways to start with custom pages, but let’s go ahead and start by creating a new app.

First thing, let’s navigate to the maker portal, so that we can start creating the new app. This was previously only available in the preview maker portal, but is now part of the default maker portal (make.powerapps.com).

To start creating the new app, click on the “+ New app” command bar button and select Model-driven from the drop down menu.

This will pop up the create model driven app from blank window, where we can select to use the Modern app designer (preview) or the Classic app designer. To start with the Modern app designer, select that choice, and click Create.

Next we will need to give the app a name, and an optional description, and click on the Create button.

After a few seconds the new app will be created, and we can start adding pages. There are three different types of pages that can be created, these are table based view and form, dashboard and custom (which is currently in preview). The animated image below shows you the three options.

We will start by selecting the table type, once selected you will have the option to select the appropriate table or tables that you want to add to your app, and with an option to add these pages to your site map as well.

When you click on the add button, you will be able to see a preview of your app directly from the designer window, basically a preview of what you app would look like. The image below shows you the preview window. You will notice that the center area is the preview, and on the left hand side we see the tables that were added to the app.

The preview area, not only shows you the way the app looks, but allows you to change the layout so that you see how the app will look in responsive design for different devices.

You will also notice the section to the left that is expanded to show the data tables, which contains links to the pages and navigation. This first link shows you the tables, dashboards and custom pages that make up your app, while the second link shows you the site map. These were covered in additional detail in a previous blog post.

New Model-Driven App Designer

Let’s go ahead and add a custom page. Under the pages left hand navigation area (or from the command bar), click on Add page, and select the Custom (preview) option. Once selected you will have the option to create a new custom page or use an existing custom page that was previously created. In our case, since we don’t have an existing custom page, we will Create a new custom page and give it a name.

Once we enter a name, this will open a new designer, and we can start working on the new app. I have added to the app a couple of galleries and commands so that we can see how this looks and works in our model-driven app. The image below shows the app that we created. Once you are satisfied with the app, click on the Save button and then publish it.

Close the custom page, and then go ahead and Save and Publish the Model-driven app that you created. The animated image below shows the end result of the custom page inside the model-driven app.

To learn how to navigate between your Canvas app and the model-driven app, you can read more about it in the following Microsoft Docs page : https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/page-powerfx-in-model-app

Custom pages can also be available by calling them from JavaScript within the Model Driven App by using the Xrm.Navigation.navigateTo function and providing a page type “custom”, and providing the name of the custom page (canvas app). You can then open the custom page inline or as a centered dialog. The following Microsoft Docs page includes samples on how to open this page: https://docs.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/navigate-to-custom-page-examples

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 Maker Portal Updates – Converged Apps appeared first on Aric Levin's Digital Transformation Blog.

There are several updates with the new designers and not all will be reviewed in these post, but I will try and highlight most of them.

In the maker portal, when you navigate to your apps section, you will see the list of both Canvas and Model Driven Apps, and you can still create your apps from here.

With just a few clicks, you can build views and forms in the maker portal, and preview your app changes within the same designer. The modern app designer is now available via the maker portal, and does not require navigating to the preview maker portal. In order to start creating a new app, click on the “+ New app” command bar button and select Model-driven from the drop down menu.

This will pop up the create model driven app from blank window, where we can select to use the Modern app designer (preview) or the Classic app designer. To start with the Modern app designer, select that choice, and click Create.

Next we will need to give the app a name, and an optional description, and click on the Create button.

After a few seconds the new app will be created, and we can start adding pages. Let’s start and review what we see on the screen once we created a new app. In the Command bar we have 7 buttons. These are Back, New Page, Settings, Switch to classic, Save, Publish and Play. Most of these are pretty obvious.

The New Page allows us to create a new page for our app, which can be either table based or dashboard. The Settings allows us to change the app name and description that we entered before, and specify whether the app will be available offline.

When you select a page type of type table-based, you will be able to select one or more tables to add to the app, and also add them to the navigation (site map).

When you click on the add button, you will be able to see a preview of your app directly from the designer window, basically a preview of what you app would look like. The image below shows you the preview window. You will notice that the center area is the preview, and on the left hand side we see the tables that were added to the app.

The preview area, not only shows you the way the app looks, but allows you to change the layout so that you see how the app will look in responsive design for different devices.

You will also notice the collapsed section to the left that is expanded to show the data tables, which contain two additional links. The first link is Pages. This link shows you the tables you have selected and the different forms and views that you have access to edit.

When a particular page (table) is expanded, in our case Accounts, you will notice that under the table you will see two options for Account form and Account view. When you click on the Account form, on the right hand side you will notice an option for managing the account form. When you click on the Manage forms link, you will be able to select which forms you want to be enabled for this page within the app as see on the image below

Within the forms that you added, if you click on the more options (three dots) at the right of the form name, you will see the options to Edit the form or remove the form.

If you click on the Edit form, this will open the form in the Maker Portal form designer (in a new tab), where you can make changes to the form directly.

The exact same applies to views. You can add the views that you want to be available to this page within the app and edit the views by clicking on the more options.

The next link is navigation. This is basically your site map. By default the site map will contain a single Area, Group and Subarea, and any additional tables that you have added to the app, either automatically when selecting the entities or manually. You have the ability to rename the areas and the groups, as well as remove any of the existing items (such as the default Subarea1, which is not necessary once you added new tables). The image below shows the navigation that is available once the new tables are created.

The main thing to notice that when setting up the new app, this is all live data. As you click through the views and the forms, you will be able to switch between them and view the live data of the different views and forms. You will also be able to see which forms and views are enabled for the app, and navigate to edit each of these and edit them from the designer directly.

When you are in your apps view, and see the list of all your existing apps (the ones created using the new Modern experience or old ones, the edit button will now have a drop down option to edit the app using the new Modern design

As this is still work in progress, not all existing apps will be editable in the modern designer, but the new apps that you create can be editable from there. Not sure yet if this is a bug, or future enhancement.

There are still some limitations to the new Modern app designer that will probably be addressed by the time this become available to the general public, or at a later data and features that are missing. You can see those by navigating to the link below:

https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/app-designer-overview

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 Maker Portal Updates – App and SiteMap Designer 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.

https://powerapps.microsoft.com/en-us/blog/introducing-the-modern-app-designer-preview/

With the new app designer, it is now easier and faster to build model-driven apps. With just a few clicks, you can build views and forms in the maker portal, and preview your app changes within the same designer. In order to access the modern app designer, we need to navigate to https://make.preview.powerapps.com/ and in order to start creating a new app, click on the “+ New app” command bar button and select Model-driven from the drop down menu.

This will pop up the create model driven app from blank window, where we can select to use the Modern app designer (preview) or the Classic app designer. To start with the Modern app designer, select that choice, and click Create.

Next we will need to give the app a name, and an optional description, and click on the Create button.

After a few seconds the new app will be created, and we can start adding pages. Let’s start and review what we see on the screen once we created a new app. In the Command bar we have 7 buttons. These are Back, New Page, Settings, Switch to classic, Save, Publish and Play. Most of these are pretty obvious.

The New Page allows us to create a new page for our app, which can be either table based or dashboard. The Settings allows us to change the app name and description that we entered before, and specify whether the app will be available offline.

When you select a page type of type table-based, you will be able to select one or more tables to add to the app, and also add them to the navigation (site map).

When you click on the add button, you will be able to see a preview of your app directly from the designer window, basically a preview of what you app would look like. The image below shows you the preview window. You will notice that the center area is the preview, and on the left hand side we see the tables that were added to the app.

The preview area, not only shows you the way the app looks, but allows you to change the layout so that you see how the app will look in responsive design for different devices.

You will also notice the collapsed section to the left that is expanded to show the data tables, which contain two additional links. The first link is Pages. This link shows you the tables you have selected and the different forms and views that you have access to edit.

The next link is navigation. This is basically your site map. By default the site map will contain a single Area, Group and Subarea, and any additional tables that you have added to the app, either automatically when selecting the entities or manually. You have the ability to rename the areas and the groups, as well as remove any of the existing items (such as the default Subarea1, which is not necessary once you added new tables). The image below shows the navigation that is available once the new tables are created.

The main thing to notice that when setting up the new app, this is all live data. As you click through the views and the forms, you will be able to switch between them and view the live data of the different views and forms. You will also be able to see which forms and views are enabled for the app, and navigate to edit each of these and edit them from the designer directly.

When you are in your apps view, and see the list of all your existing apps (the ones created using the new Modern experience or old ones, the edit button will now have a drop down option to edit the app using the new Modern design

As this is still work in progress, not all existing apps will be editable in the modern designer, but the new apps that you create can be editable from there. Not sure yet if this is a bug, or future enhancement.

There are still some limitations to the new Modern app designer that will probably be addressed by the time this become available to the general public, or at a later data and features that are missing. You can see those by navigating to the link below:

https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/app-designer-overview

The post New Model-Driven App Designer appeared first on Aric Levin's Digital Transformation Blog.

These include:

• Creating an AutoNumber for the current entity
• Create an AutoNumber for an entity based a value in a related entity, and stores the AutoNumber in a text field in the entity
• Create an AutoNumber for an entity based a multiple values of a related entity, and stores the AutoNumber in a text field in the entity
• Create an AutoNumber for an entity based a value in an option set field, and stores the AutoNumber in a text field in the entity
• Create an AutoNumber for an entity based a multiple values of an option set, and stores the AutoNumber in a text field in the entity

The source code, documentation and managed and unmanaged solutions are now available on Github, and can be downloaded from here:

https://github.com/ariclevin/autonumber/tree/master/Enterprise

The post Advanced AutoNumber Source Code now available appeared first on Aric Levin's Digital Transformation Blog.

The series will cover 6 different blogs posts, which include the following: prerequisites (creating the entities for the model-driven app, creating the base for the flows). We assume that you already have an Eventbrite account that you can test this with, configuration of Eventbrite (setting the api and configuring the webhooks), creation of the custom connector, creation of the event flow to create a new event in CDS when a new event is created in Eventbrite, creation of the attendee flow to create a new attendee when an attendee is added to an event in Eventbrite, and finally running the tests.

The first post will concentrate on creation of the entities and the baseline flows. This is required for all the posts that will come after. The first step is to create a solution and then create or add the entities to the solution. For the purpose of this series of posts, we create a single Event entity, and make some changes to the Contact entity where we will store the values for the attendees of the event. You can create a different entity to store the attendees’ information if you would like.

The screenshots below show the fields that are used for the Event entity and the Contact entity. You should also customize the views and forms in order to display the fields that you want, and not only the default fields. We will create an app for this solution later on.

* Note: The Contact Entity is not ideal for this scenario (as Contacts can exist in multiple events), but was used in order to simplify the process.

Once we have created the two required entities, we will create two flows for capturing the webhook from Eventbrite when an Event is Created/Updated and when an Attendee is Registered/Unregistered. To create a flow, within your solution click on the New button and select Flow. This will launch the Flow designer. In the search for trigger type HTTP, and select the When an HTTP request is received.

This will show the Flow with the When a HTTP request is received trigger. There are a few properties in the trigger that need to contain data. The first is the HTTP Post URL which will be generated when the Flow is Saved. The other is the Request Body JSON.

{
    "type": "object",
    "properties": {
        "config": {
            "type": "object",
            "properties": {
                "action": {
                    "type": "string"
                },
                "user_id": {
                    "type": "string"
                },
                "endpoint_url": {
                    "type": "string"
                },
                "webhook_id": {
                    "type": "string"
                }
            }
        },
        "api_url": {
            "type": "string"
        }
    }
}

The post Eventbrite to CDS Integration – Part 1 appeared first on Aric Levin's Digital Transformation Blog.

Once you have created your account and are logged onto Eventbrite, on the top banner, click on the arrow next to the profile picture and select Account Settings.

This will load the Account Settings page. At the bottom of the Account Settings navigation, there are two items available under Developer Links API Keys and Webhooks. We will first configure an API key.

Click on the Create API Key button. A new form will pop ask asking for contact information, application Url, oAuth Redirect URI, Application Name and Description. Enter the details for your application. Once this information has been entered, you will see the name API Key details under the API Key

Copy the data from the Api Screen. You will need it for later in the process. You can always come back to Eventbrite account settings and copy these values again.

The next thing that we need to do is Add two Webhooks. The first is for the Event creation and the second is for the Attendee registration. Based on the way that you configure Eventbrite and the type of events that you have, you might want to configure additional webhooks. In order to add a Webhook, we need to provide a Payload URL. Since we are going to use flows (Microsoft Power Automate) to receive the HTTP requests, we need to create those first and get the Url addresses from them, which is what we did in the previous section.

Events Webhook:

Attendees Webhook:

1 – PREREQUISITES | 2 – EVENTBRITE SETTINGS | 3 – CUSTOM CONNECTOR | 4 – EVENT FLOW | 5 – ATTENDEE FLOW | 6 – TESTING

The post Eventbrite to CDS Integration – Part 2 (Eventbrite Settings) appeared first on Aric Levin's Digital Transformation Blog.

There are a few custom entities which assist in the design of the layout of the subgrid, and well as javascript files that make up this logic.

The main different between this and the SharePoint grid is the ability to add additional attributes to the files that are being uploaded (as they are being uploaded).

The image below shows the subgrid that is displayed when the form loads. These documents have been uploaded from the subgrid web resource, and notice that the following attributes are also contained as part of the results: Account Name, Account Number and Document Type.

When uploading a new document, the application pops up a File Upload control with a picklist to select the document type that will be uploaded (as shown below).

When the document is uploaded, the Account Id, Account Number, Account Name and Document Type are set as attributes in the SharePoint folder. Also, all the documents that are pertaining to a single record within Dynamics, are uploaded to a single folder within SharePoint. The folders are Grouped by Entity Name and Entity Id, so that they are unique. The image below shows how the documents look in SharePoint after they are uploaded.

From the previous posts, the entire solution requires Configuration of SharePoint, Configuration of Azure, Development of the Web Api and the development of the HTML Web Resource. I am providing the source code of the entire implementation has been uploaded to my public github repository, and is available for download along with the CRM (Dynamics 365 v9) solution.

This is a customizable solution and requires certain configuration, so not really for the faint of heart.

Hope you enjoy this.

The post Dynamics 365 and SharePoint Online Integration – CRM Implementation appeared first on Aric Levin's Digital Transformation Blog.