How to install a PowerApp Solution when the “Active” Solution is missing

How to install a PowerApp Solution when the “Active” Solution is missing

As part of the forthcoming 2020 Wave 2 or October release of the Power Platform a few more items are being upgraded to reflect the additional functionality. Of which one of the biggest ones is the Solution Import routine.

However alongside all the improvements (Environment Settings, Connections) the actual import routine has gone backwards and currently the error message for missing dependencies is both cryptic and completely useless.

Where previously you would be greeted with a list of missing dependencies and what they were

You are instead greeted by the message “There are missing dependencies. Install the following solutions before installing this one: “Active”

Which makes identifying the issue impossible.

Resolving this is however easy to do so – from the make.powerapps.com Solutions list click “Switch to Classic” mode

That will open up the old Solution screen from where you can click Import Solution

and you can reimport the solution file and get a more suitable message. But note, there is another issue here as currently even this view is reporting that the missing Solution is called “Active” when it actually I know the missing solution is the “BareBones – Sales Core” solution I removed to allow me to take the screenshots.

Why we’ve released and open sourced BareBones CRM

Why we’ve released and open sourced BareBones CRM

Introduction

Last year when I left Microsoft for the second time it was with the ambition of launching as an Independent Software Vendor (ISV) and as a consequence ideally stop the weekly flights across Europe.

At the same time a previous customer approached to see if it would be possible to create a cheaper Customer Relationship Manager solution that more accurately met their needs. While they were using Dynamics 365 I think we had spent longer removing functionality instead of adding to it (as is often the case) as they really only needed a means of track birthdays, basic leads, opportunities and send customer service requests to the appropriate person / team.

So taking their money and focussed very much on the new $10 per app per user per month license we set to work and created the solution they needed – the solution that now forms the basis of BareBones CRM.

On finishing the work we delivered it and then started to talk to a few other partners to see if they had customers who had similar needs – and although they did we also discovered a fundamental problem so we left things there.

Background

Over the last two weeks, however, a couple of things have changed and that meant we dropped everything on Friday to open source BareBones CRM so let’s explain what they are.

  1. For the past year I have had a number of conversations regarding Restricted (and other) entities that appear in Microsoft’s Common Data Model but do not appear in the none Dynamics 365 / core Power Platform Common Data Service Dataset. About 2 weeks ago I had a linkedIn conversation with Ben Vollmer which implied the idea was no longer on the radar – see https://www.linkedin.com/feed/update/urn:li:activity:6706920588767739904/?trk=public_post-embed_share-update_comments-text
    Now this is important for a reason we discovered last year and that we will get to in a minute.
  2. at roughly the same time Steve Mordue announced ISV Connect ED a website designed to create a community of ISV to provide support and advice – now I have no problems with that but it’s interesting that he’s done that when
  3. on Thursday (September 10th) Steve Mordue announced that RapidStartCRM was now free with a change in focus to grow the market and sell custom development instead.

There can be only one (Entity Reference)

Now, you may remember in the Introduction that when we finished the Barebones CRM we started to talk to other partners and then stopped. There is a simple reason for that, the way Entity References work means that if you are creating a solution that enhances opportunity management and you create a connection between your new entity X and Dynamics 365’s opportunity entity you cannot then modify that link to talk to the opportunity entity in BareBones CRM or RapidStartCRM – the ISV needs to start again almost from scratch. Which poses a serious problems for ISVs who may wish to target both Dynamics 365 and Power App users with the same solution.

Now I was hoping (see point 1) that Microsoft were aware of the issue and were working towards making the entity definitions available. If that had occurred things would be easy for ISVs as anyone providing core sales functionality could create an Opportunity entity with the same name as the one within Dynamics 365 and the ISV could just point at the opportunity entity and instantly support any and all core sales solutions. But sadly Ben’s comments implies that whatever attempts Microsoft have made in that direction have failed.

And with that news our original plan to keep Barebones CRM ticking over as an internal project until we had access to the core entities definitions and could create an ISV (and customer) friendly solution which allowed everyone to target a single entity definition disappeared. So we made a decision that we would find time in the next few months and release the BareBones CRM as open source for others to use.

Then Thursday arrived and we discovered that we probably should hurry things along – so we have.

Which means

  1. if you are an end user who wants a free simplified CRM solution that runs on the Power Platform there are now two options – and while BareBones CRM isn’t on Appsource now but we aim to have it there within the next 2 weeks. Equally we expect to finish the website, add documentation and a support forum for those who need it
  2. If you are a partner / ISV who wish to offer such a solution to their customers there are two options – one of which is “Free as in Beer”, can be downloaded via Appsource and is supported by a company who would like to do your customer’s customisations themselves and BareBones CRM which is you can find at https://www.barebonescrm.com with unmanaged solutions available at https://github.com/BareBones-CRM/Core which you can enhance and develop however you want.

And finally, if you find BareBones CRM useful we would love your contributions (be it translations, enhancements, bug reports, bug fixes)…. but there is no pressure…

How to personalise the URL of your Power App Environment

How to personalise the URL of your Power App Environment

One thing that was always obvious in the Dynamics 365 world that until now wasn’t clear (to me at least) in the Power App world was how to give your Application a sensible and memorable URL that wasn’t org followed by a random set of digits such as org123653dd.

Last night, trying to work out how to do something else, I discovered how to do it so below is a step by step guide.

Step 1
Starting https://make.PowerApps.com click the cog and select “Admin Center”

Step 2
Click the environment you want to customise

Step 3
Update the Url (and the name if you desire) to something more sensible

If the choosen Url is already taken you will see an error message like the one below

so just move on to the next appropriate name until you find one that hasn’t already been taken at which point the form will save and you will return to the previous screen

And your environment will now have a far more user friendly and professional name that you can share with your co-workers.

Opening Entity records with Xrm.Navigation.NavigateTo

Opening Entity records with Xrm.Navigation.NavigateTo

One thing I’ve been waiting a while for is the functionality that allows an entity record (say Opportunity Close) to be opened as a modal window in front of the current window.

Now I know that I could already do this with a Quick Create Form but that results in the Entity appearing in the Quick Create list which may not be the desired result if you want to use the entity to close a task or process (say on Case close or Opportunity won) rather than starting a new task.

The 2020 wave 1 April / May release finally offers the option with Xrm.Navigation.navigateTo, but as it differs in a couple of ways from the old Xrm.Navigation.OpenForm command and has a nasty context issue that will catch you out, it’s worth going over it in more details.

Using navigateTo

The command itself is:

Xrm.Navigation.navigateTo(pageInput,navigationOptions).then(successCallback,errorCallback);

and because it’s a generic command you can play with this yourself on any entity form by opening your browser’s developer console, and entering the following command.

Xrm.Navigation.navigateTo({pageType:"entityrecord", entityName:"contact"}, {target: 2, position: 1, width: {value: 50, unit:"%"}});

And as this is a modal window you can only access the contact record, the account record beneath the record is inaccessible. Only when you close the window can you edit the old record.

Expanding and closing

The modal window offers 2 right hand navigation options, one that maximizes / minimizes the modal window size, the other closes the window.

navigateTo has two input parameters, a pageInput object that determines what will be displayed, and a navigationOptions object that determines how and where it will be displayed.

pageInput

the pageInput object uses the following attributes:

pageType

A required String either “entitylist”, “entityrecord”, “webresource”

entityName

The logical name of the type of entity the entitylist or entityrecord will be displaying

entityId

The id / guid of the entityId to be displayed *if you want to show an existing record. The Guid is without brackets {}.

data

A dictionary object of any fields you wish to prepopulate as you create the new record. For instance {hdn_closetype:”lost”}. This is identical the form parameters that were passed separately when using Xrm.Navigation.openForm.

createFromEntity

allows you to pass in a Lookup to prepopulate the new record with the mapped attribute values specified in the relationship between the lookup and the new record. The lookup object has 3 attributes, entityType, id and name (optional). While the name field is optional where possible you should pass it within the object as otherwise the system will display a default value which may cause confusion.

Note: https://docs.microsoft.com/en-us/powerapps/developer/model-driven-apps/clientapi/reference/xrm-navigation/navigateto lists another set of options but I will ignore those for now as they relate to Business Process Flow requirements that I suspect most people won’t need to worry about.

Navigation Options

target

Target is a required (number) field that offers two options:

A value of 1 opens the form inline (replacing the current page), 2 opens the form in a dialog -which is what we require for our purposes.

Note: web resources and entity forms can be opened both inline (target:1} and as a dialog {type: 2} but entity lists can only be opened as an inline resource.

One of the catches we have discovered will show why later.

Position

Only used for Dialog windows (target:2}. 1 opens the dialog in the center, 2 opens it to the right (same as a Quick create form).

Size

Width and optionally height can be set using a SizeValue type {value: Number, unit: string either “%” or “px”}

Return Values

As with most functions in the Xrm library Xrm.Navigation.navigateTo returns a promise. When the return is triggered depends on the target of the window, for inline targets {target:1} (replacing the existing page) the promise is resolved immediately, for dialog targets {target: 2} (modal window / dialog on top of the existing window) the promise is resolved when the dialog is closed.

If an entityrecord is opened in a dialog in create mode the promise will receive a savedEntityReference array to identify the created record.

var pageInput = { 
	pageType: "entityrecord", 
	entityName: "account" 
}; 
var navigationOptions = { 
	target: 2, 
	position: 1,
	height: {value: 80, unit:"%"}, 
	width: {value: 70, unit:"%"} 
}; 
Xrm.Navigation.navigateTo(pageInput, navigationOptions).then( 
	function success(result) { 
		console.log("Record created with ID: " + result.savedEntityReference[0].id + " Name: " + result.savedEntityReference[0].name) 
		// Handle dialog closed 
	}, 
	function error() { 
		// Handle errors 
	} 
);

Resolving the promise is actually more important than you would expect as issues with context I’ve discovered below will reveal.

The issue of Context

The new functionality is sadly not perfect. As I’ve been playing with the functionality, I have encountered two separate issues connected with the system’s awareness of current context which could cause problems.

Adding a second record

Clicking New in the modal window may not do what you think it will do. It doesn’t as you might expect reopen open a fresh form in the modal window it instead opens it in the main form overriding what was previously there.

Context

The second issue requires a tiny bit of background knowledge, that D365 / powerapps remembers in the background the current entity / entity Type it is dealing with.

Now that has never previously been an issue as there has only ever been 1 core entity on the screen but now you can add a second (or even a third, by using both positions) entity it’s no longer so clear cut and the newly created / saved record will override the information in the background.

The video below shows a quick example of the issue – as the contact record is saved the context is switched from account to contact as pressing F5 in this video shows.

F5 form refresh doesn’t work

As you can see upon saving the contact form in the dialog window the application context switched from the account record you half expect it to be to the contact record that had been closed.

To avoid this and return the context to what the user is probably expecting (the account record) you need to refresh / reload the account form within the success function of the promise.

The code sample below does exactly that. As part of the initialisation of the dialog window we create a separate object containing the account information so that when the dialog is successfully closed we can refresh / reload the account window and the context is restored.

this.resolveCase = function(context){
var id=context.data.entity.getId().replace(/[{}]/g,"");
var ef = {};
ef["pageType"]= "entityrecord";
ef["entityName"] = "contact";   ef["formType"]=2;
    ef["cmdbar"]=false;
    var createFrom ={};
    createFrom ["entityType"]= "account";
    createFrom ["id"]= id;
    createFrom ["name"] = context.getAttribute("name").getValue();
    ef["createFromEntity"]=createFrom;

    var es = {};
    es["entityName"] = "accounbt";
    es["entityId"]=id;

    Xrm.Navigation.navigateTo(ef, { target: 2, position: 1, height:{value: 600, unit:"px"}, width: {value: 500, unit:"px"}}).then(
        function(){Xrm.Navigation.openForm(es)});    
};

Dynamics 365 – Restricted Sales entities

Back in August/ September 2019 when Microsoft announced the license changes to Dynamics 365 and the Power Platform as part of the wave 2 2019 release Microsoft also announced changes to the list of restricted entities that require a full Dynamics 365 license.

Annoyingly 5 months later that list of restricted entities has still not been updated which is fine until a customer asks, “Can we use the product entity outside of Dynamics” and you disappear off to answer the question only to discover there is no answer.

So last week we decided to do an experiment and see if it is possible to identify the entities that exist in Dynamics 365 but do not exist in freshly created Common Data Service / Power Platform application environment.

This post is the first of a number of posts listing Dynamics 365 entities that don’t exist in non Dynamics 365 / standard Power Platform environments.

For convenience, we are going to display things on a Solution by Solution basis. So here are the Sales related Entities in the msdynce_Sales solution.

D365 Sales Entities not in available in PowerApps

Entity NameEntity System NameNotes
Competitor Competitor?
Competitor AddressCompetitorAddressHelper Entity
Competitor ProductCompetitorProductHelper Entity
Competitor Sales LiteratureCompetitorSalesLiteratureHelper Entity
Contact InvoicesContactInvoicesHidden
Contact OrdersContactOrdersHidden
Contact QuotesContactQuotesHidden
Customer Opportunity RoleCustomerOpportunityRoleHelper Entity
DiscountDiscount ?
Discount TypeDiscount TypeHelper Entity
InvoiceInvoiceProbably Restricted
Invoice DetailInvoiceDetailProbably Restricted
LeadLeadProbably Restricted
Lead CompetitorsLeadCompetitorsHelper Entity
Lead ProductLeadProductProbably Restricted (join on two entities that are both probably restricted)
Opportunity OpportunityProbably Restricted
Opportunity CloseOpportunity Closetied to opportunity
Opportunity CompetitorsOpportunity Competitorstied to opportunity entity
Opportunity ProductOpportunityProduct Probably Restricted (there is lot of business logic behind here)
Order CloseOrderClosetied to Sales Order entity
Product Price LevelProductPriceLevelProbably restricted (join on two entities that are both probably restricted)
Product Sales LiteratureProductSalesLiterature?
QuoteQuoteProbably restricted
Quote CloseQuoteClosetied to Quote entity
Quote DetailQuoteDetailProbably restricted (there is lot of business logic behind here)
Sales LiteratureSalesLiterature??
Sales Literature ItemSalesLiteratureItem??
Sales OrderSalesOrderProbably Restricted
Sales Order DetailsSalesOrderDetailProbably Restricted (there is lot of business logic behind here)

So that’s the Sales side of things – where there are a number of likely entities due to the business logic that occurs behind them.

Next I will move on to the product side of things before looking at Marketing, then customer service and finally some other interesting bits and pieces.

And yes there should be a sales pitch here but I will leave that until everything else is set up and ready to go.