Command bars are at the core of every model-driven app and appear in many different locations. They are arranged in relation to other commands and are associated with a command bar location. The group of commands associated with a specific location make up a command bar.

One of the biggest deficiencies of the Classic Commands, formerly known as the Ribbon, is that there is no low code solution to customize these commands. Command bars can be difficult to customize and error prone (although life has been simplified with the Ribbon Workbench by Scott Durow).

Modern command bars address some of the gaps and difficulties that we had with the legacy commands, and provide support for both Power FX and JavaScript.

Let’s go ahead and take a look at how we can implement modern commanding within our apps. I will use one of the apps that I previously created for this, and add a command bar button that will use Power FX to show/hide the button as well as a custom function that will execute on the click of the button.

In order to start using the new Command functionality, we first need navigate to the page (table in this case) that we want to work with, and select the Edit command bar (preview) option by clicking on the more options to the right of the table name and selecting that option as shown in the image below. This has to be achieved from the Pages navigation pane.

This will pop up a dialog where we have to select what command bar we would like to customize. There are four available options to select which include the Main grid, Main form, Subgrid view and Associated view. The image below shows these options.

Let’s go ahead and select Main form. When the Commands page open, we will see a view that contains all of the existing command bar buttons that are available for the table within the Main form. At this point in time (as this is still in preview, and we don’t know the exact timeline of release), modifying the existing buttons is not currently supported, so any customizations that is needed for this, will have to be done using Ribbon Workbench. The image below shows you the Main form Command Bar before we have added any additional buttons.

Now let’s go ahead and create a new command. We will create a simple command that is called Calculate Credit Limit which when clicked will multiple the number of employees in the company by 10,000, and will set it to only be visible when the number of employees contains data.

To start creating a new command, we click on the new Command button on the top of the left navigation pane.

Once we click on the new command button, we will see that a has been created. We can move the command (using drag and drop) within the Main form to place it in the appropriate location, however this can only be done for new commands, and not the existing ones. Let’s provide the new command some of the properties, such as the Label, Icon to use and the Tooltip text.

Next, we would like to set the functions for the Action that will be performed when the button is clicked as well as the Visibility of the button. On the right Command Pane, the last two options are Action and Visibility. The Action selection has two options: Run formula and Run JavaScript.

If we use the Run JavaScript option we can provide the name of the library and the name of the function to call when the button is clicked. This is more of a legacy type of action which might be used in the future for enabling the legacy buttons. The Run formula allows us to Run Power FX code when the command is clicked.

We can use the Patch function together with the Self.Selected.Item together in order to update the Credit Limit, and then compare the Number of Employees to Blank to control the visibility of the button. I am still working a few glitches as to what is working and what is not when it comes to Power FX for commanding, but the code below is working properly.

On Select:

Set(TotalCredit, Self.Selected.Item.’Number of Employees’ * 10000);

Patch(Accounts, Self.Selected.Item, {‘Credit Limit’: TotalCredit});

Visible:

Self.Selected.Item.’Number of Employees’ <> Blank()

The following Microsoft Docs pages provide an overview of Modern Commanding, directions on the use of the command designer and how to use Power Fx for modern commands.

• https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/command-designer-overview
• https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/use-command-designer
• https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/commanding-use-powerfx

Now, let’s look at the end result after adding the button and publishing the app commands.

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 – Modern Commanding 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 quite a bit of update with the new solution explorer, so I will not review all of them, but just some highlights about them.

The new solution explorer, which is now in public preview is enabled by default for any instance and organization that received the update. When you navigate to solutions in your maker portal after the update has been applied, the first thing that you will see is the following screen. You will get a popup stating that Solutions have a new look, and you have a toggle option that allows you to turn it off (until it is out of preview).

Once you click on a solution, this will open the solution showing a similar view of all the solution components (as with the previous version), but will also include two new areas. The image below shows the new layout.

Let’s take a look at the middle area first. This area is a tree view that categorizes all of the solution components, so that you can easily find what you are looking for. It will only show the components that are part of the solution, and not all available components, you will be able to click on each one of these (such as Cloud Flows or Tables), and it will filter the main view to only display these.

Some of these components, such as table have special characteristics, because you can dive into the individual elements. When you expand the tables, it will show you the list of tables, and then when you expand an individual table, it will show you the list of subcomponents of the table such as columns, relationship, business rules, views, forms, etc… The screenshot below shows an expanded view of the solution.

Next, let’s look at the overview and the history sections of the solution. When we click on the Overview button, the screen is divided into 4 sections. These are the Details section, Solution status, Dataverse search and Recent items view. The image below shows the view of the Overview page.

The Details sections provides some basic information about the solution such as the Name, Publisher, Package Type, Version and Description. Most of these items can be edited by clicking on the Edit Details hyperlink on the header of the Details section, which will display a pane on the right hand side.

The solution status overview section shows you whether Solution checker has been run and the results, and if not provides a link to Run the check.

The Dataverse search provides the ability to see which tables are being indexed, add additional tables to be indexed or remove existing tables from the database search. Dataverse search can be enable for a particular instance in the Power Platform Admin Center under Environments -> Settings -> Features, and just turning the toggle to the On (recommended) position. For more information about Dataverse search you can visit the Microsoft Docs page below.

https://docs.microsoft.com/en-us/power-platform/admin/configure-relevance-search-organization

The Recent Items section shows you a list of the 5 most recent components that you have worked on, and you can navigate to the components directly from the overview page.

Finally, the History page show you a list of operations that were performed on the solution (such as Exporting, Importing, Publishing, etc…), and the status of each of those operations. This can also help at times when Upgrading solutions from one environment to the other, which might take a long time, so the status of these upgrades can be viewed. An image of this view is shown below.

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 – Solution Explorer 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 new connector comes with exciting and awaited features. The connector includes the features that are available in the current version of the connector, but also includes additional features to make it easier to build flows for CDS. The first thing to understand about this connector is that it is only available for access from within a solution and not by starting a new flow.

In order to use the connector, you will have to go to Solutions in Flow or PowerApps, select your solution, and then add a New Flow Component. Once you add the flow component you will be able to add the new Common Data Service (current environment) connector to your flow. The new connector has a single trigger, which is named When a record is created, updated or deleted.

When this trigger is selected you can choose from a variety of trigger conditions that will execute on Create, Update, Delete or any combination of these triggers. You will also be able to specify filtering attributes, so that it will execute an update only on changes to particular fields.

The new connector comes with 6 new actions in comparison to the Common Data Service connector. These actions are: Perform a bound action, Perform an unbound action, Relate records, Unrelate records, Executes a changeset request and Predict. I will describe each of these in further details below.

The Relate and Unrelate records are pretty similar, and follow the same logic as the Associate and Disassociate messages in Model-Driven/Dynamics Apps. You provide the name of the entity, the id of the entity record, the relationship name and the Url of the related entity record, which will be the oData Id dynamic content property, as shown in the image below.

The perform a bound action that is used to call actions that are bound to particular entities. This can be used to trigger both our of the box actions such as SendEmail and QualifyLead or even custom actions such as msdyn_CloseQuoteAsWon or msdyn_CloseQuoteAsLost.

Based on the action that is being entered, the required list of parameters and options will be displayed in the Perform a bound action. There is no validation of required parameters in Flow, so if a required parameter will not be entered the Flow will fail. The perform an unbound action, is used to call actions that are not bound to a particular entity type, such as Win Opportunity and CloseIncident, or also for using SDK specific operations such as CloneAsSolution, ExportSolution, PublishXml, GrantAccess and many more.

Just like the Perform a bound action, the Perform an unbound action will display the list of required and optional parameters for the particular unbound action. The full list of Bound and Unbound actions are available on the Microsoft Docs web site. See the links below for reference:
https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/webapi/use-web-api-actions
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/web-api/actions?view=dynamics-ce-odata-9

In addition to the above additions, we also have the Predict and Executes a changeset request action in the new connector. The Predict is an AI Builder trigger, that triggers a particular AI Model (such as TextRecognition model or BusinessCard model) and receives an output response. The Executes a change set request will execute multiple change requests in a single batch. The operations in the change set are considered atomic, which means that if any one of the operations fail, any of the completed operations will be rolled back.

In addition to all of the new actions that were added to the new Common Data Service (current environment) connector, there are some additional changes that were added to the List records action

These operations are Select Query, Fetch Xml Query and Skip token. The Select Query limits the properties that are returned when retrieving data. The Fetch Xml query is a FetchXml query that you can control for selecting, filtering and ordering the attributes that are retrieved.

Additional information about this connector is available on the Microsoft Docs website.
https://docs.microsoft.com/en-us/connectors/commondataserviceforapps/

Note: This connector is not currently available in US Government (GCC) region.

The post What new in the Common Data Service Connector? 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.

In the recent weeks I saw a few posts in the community of people asking how to do this. In this article I will demostrate the logic of implementing this.

The first thing is we are going to need to create an Entity for the purpose of this solution, and add a button to the entity form to popup the message. We created an entity called Area Type and added a button to the entity called Change Owner using Ribbon Workbench. The button itself will call a JavaScript function that is called changeOwner.

The Change Owner function contains the code snippet below which calls the dialog and also processes the changes from the callback of the dialog. I am using the Xrm.Internal.openDialog to open the web resource, and yes “I am aware that this is not supported”, but this is still working in Dynamics 365 v9, and you can feel free to modify the calling of the web resource. Once the button is clicked the popup window will open.

function changeOwner()
{
    var DialogOption = new Xrm.DialogOptions;
    DialogOption.width = 600; DialogOption.height = 550;
    Xrm.Internal.openDialog("/WebResources/xrm_dialog.htm", DialogOption, null, null, changeOwnerCallback);
}

function changeOwnerCallback(returnValue) {
    if (returnValue != null) {
		
		// If need to return multiple values;
	    var returnValues = returnValue.split(':');
        var ownerId = returnValues[0];
        var ownerName = returnValues[1];
		// Perform Actions on return values
		setLookup("ownerid", ownerId, ownerName, "systemuser");
    }
}

Since this was used in a previous project that we had, there is a text box for comments and the lookup control that will need to be popped up.

When the user clicks on the lookup icon in the dialog window, an additional Lookup Record window will pop up on top of the original dialog window.

function openOther() {

	var imgButton = $("#crmOtherLookup").attr("src");
	if (imgButton == "/_imgs/btn_off_lookup.png") {


		var objectTypeCode = 8;
		var url = "/_controls/lookup/lookupinfo.aspx?AllowFilterOff=0&DefaultType=8&DefaultViewId=%7bE88CA999-0B16-4AE9-B6A9-9EDC840D42D8%7d&DisableQuickFind=0&DisableViewPicker=1&IsInlineMultiLookup=0&LookupStyle=single&ShowNewButton=0&ShowPropButton=0&browse=false&dType=1&mrsh=false&objecttypes=8";

		var DialogOption = new Xrm.DialogOptions;
		DialogOption.width = 500; DialogOption.height = 400;
		Xrm.Internal.openDialog(url, DialogOption, null, null, openOtherCallback);
	}
	else {
		alert("Please select the radio button to the left of Other in order to select a system user.");
	}
}

function openOtherCallback(returnValue) {
	if (returnValue != null)
	{
		if (returnValue.items.length > 0) {
			var guid = returnValue.items[0].id;
			var name = returnValue.items[0].name;
			$("#crmOtherLookup_ledit").val(name); // text 
			$("#crmOtherLookup_lId").val(guid); // hidden                    
		}
	}
}

Select the User record that you want, and click the Add button to populate the values from the lookup window (as shown below):

Finally press the OK button to have the data from the lookup returned to the form, and update the original lookup field that is on the form (not required).

function applyChanges() {
	var returnValue = "";

	var message = $("#crmRoutingMessage").val();
	if (message != '') {

		var otherId = $("#crmOtherLookup_lId").val();
		var otherName = $("#crmOtherLookup_ledit").val();
		returnValue = otherId + ':' + otherName; 

		Mscrm.Utilities.setReturnValue(returnValue);
		closeWindow(true);
	}
	else
	{
		alert('Please enter a Routing Message');
	}
}

The full source code and a sample solution (containing the test entity, customizations and all web resource files) is available here on github: https://github.com/ariclevin/WebResourceLookup

The post Creating Web Resource with a Lookup Control appeared first on Aric Levin's Digital Transformation Blog.

This is where it becomes tricky, as some entities cannot be easily cloned due to some of the restrictions, so we wanted to provide this solution the ability to restrict certain actions from happening. For example, the address1_addressid and address2_addressid fields in the Account and Contact entities cannot be cloned as they point to the Customer Address record, so the Guid there has to be unique.

So for the first scenario, we needed to provide the system with the ability to restrict certain fields from being cloned, by providing a status of Active or Inactive, the cloning solution will decide whether or not to clone the record. The screenshot below shows the Clone Settings entity, with the list of attributes that are available for cloning. Notice the highlighted row is marked as Inactive., which means it will not be cloned.

Next we had to deal with relationships. One of the issue with relationships is that there are probably many relationships that you do not want to be cloned. In the related entities, we provided 3 statuses: Duplicate, Reassociate or Inactive. The Inactive option skips the cloning procedure for the relationship. The Duplicate will make a duplicate of the record Related entity record and the Reassociate will reassociate the related lookup from the source record to the cloned record.

We modifies the application ribbon so that the Clone button will appear on every entity (based on a webapi call to check if the entity is enabled for cloning in the Clone Settings), and added a global script library for this purpose on for calling the Clone action. The end result is as follows.

This solution works for our purpose, but I would consider it a Beta Release for anyone who is interested in source code. It’s available on github, so you can make whatever changes that you want. I will add instructions on how to use sometime soon.

The post Global Cloning functionality for Dynamics 365 appeared first on Aric Levin's Digital Transformation Blog.

We removed all of the references to the entity, and the entity got deleted. So far no issues. One of the developers on the project created an action which one of the Input Parameters was an Entity Reference to the deleted entity. After the entity was deleted, when the developer tried to open the Action, he got a Query error, and could not open the action. In the Url of the designer we could see that there was an error that said “Entity xyz_customentity does not exist in the metadata cache”.

After a little brainstorming, we exported the action (as a solution), and found the Xml of the input parameter that was pointing to the entity. We could remove the Input Parameter Xml and reimport the solution and hope that everything would work, or the probably easier solution was to just recreate the entity (no extra customization needed) and keep the same schema name.

We recreated the entity, and immediately the action opened up. We then went on and removed the Input Parameter that was causing the issue, activated the action and deleted the entity. Quick Fix to an annoying problem.
The bottom line is this this should probably not happen.

I submitted this to ideas.dynamics.com. If anyone is interested in voting up this idea, you can click on the following link:
https://ideas.dynamics.com/ideas/dynamics-crm/ID0003925

The post Action Parameters referencing deleted entities appeared first on Aric Levin's Digital Transformation Blog.

The portals are compatible with the Online and On-Premise version 8.1 and later. The important thing to note is that this source code is provided to customers that are unable to deploy portals in an online environment, and are willing to maintain the portals code internally. Microsoft is not planning on supporting this code, which is also why it is provided under the open source license, and at the point of writing this, there are not acknowledgements of whether or not this will be supported in the future.

The download contains the solution files, the source code and the deployment instructions of the source code. The integration with the Portals web application can be implemented using a internal/organizational IIS server or using Microsoft Azure.

You can download the portals from the following link:

https://www.microsoft.com/en-us/download/details.aspx?id=55789

The post Microsoft Dynamics 365 Portals Source Code Available for On-Premise Customers appeared first on Aric Levin's Digital Transformation Blog.