Recently I participated in a group discussion with Colin Vermander about what it takes to have a successful implementation of Dynamics 365 Portals. Among many other factors that I’m sure we’ll discuss in the future, one that struck me is how to build the perfect Portals Implementation team
I thought it would be fun to take a look at the skillsets that are needed to build that team, and the roles associated with those skillsets. Now let’s make the distinction clear before we get started that many of these roles overlap, and the people who fill these roles simply need to have the skillsets required. Very often, one person might fill multiple roles on a smaller project. For example, the Business Analyst and Functional Consultant might be the same person. Conversely, on large implementations with tight deadlines, you might have a very large team with multiple workstreams. Each workstream might have a team of BAs, its own dedicated functional, solution architect, and development team. The golden rule at the end of the day is to ensure that the project is not understaffed, and that each of the below skillsets is taken into consideration when building your team.
Also note, that this article tries to be methodology-agnostic as much as possible. Some roles might only apply to certain methodologies – for example if you are using scrum you’ll need a scrum master, etc. Alright, without further adieu, let’s get down to it.
Continue reading “Building the Perfect Portal Team”
In the last article I wrote on this subject, we talked a bit about the Create Portal Content wizard. In that article, we walked through creating a list of leads that displays on the portal. Anyone can access the list, and it’s read-only. Where can we go from here?
Perhaps we don’t want to allow any anonymous users to see our lead list because we only share this information with partners, for example. In this case, we want the ability to create new leads or edit existing leads from the portal, or to take actions on those leads. In other words, we want a secure list of leads that can be modified by those with the appropriate permissions.
For now, let’s not worry about the realism of this scenario. In a future post, I’ll show you how to build out an awesome portal, and we’ll look in more detail at a realistic business use case at that time. For now, let’s use this simple example to build our knowledge of how to manage permissions for entities exposed on the portal.
Continue reading “Basic Portal Entity Permissions and the Create Content Wizard”
Just this past December, Microsoft announced the ability to enrich model-driven forms with embedded canvas apps – and this is really exciting. Since I first started working with the power platform, the fact that canvas apps and model-driven apps don’t really play together has seemed a notable limitation. This enhancement really helps bring everything closer together because we can get the same pixel-perfect purpose-driven UI that we’ve come to love (and we all know we do) about canvas apps but within a fully functional model-driven application. In case you are wondering, yes this does potentially open the door to embedding canvas apps within UCI for Dynamics 365 as well (since UCI for Dynamics is essentially a model-driven app).
First off, it takes only a few clicks to embed a canvas app on a model-driven form. Canvas apps are easy to develop (hence the somewhat-maligned concept of the citizen developer) and you can craft very nice visual layouts with “no coding” required (in fact it’s the same level of coding that you’d be using with custom excel apps for example). Furthermore, to bring in and display data from external services, you can choose from a long list of connectors that PowerApps offers for popular services such as SharePoint and Office365 or they can create custom connectors. Finally – and this is important – you get the context of the model-driven form passed in to the canvas app – including the current record or list of related records.
Continue reading “Embedded Canvas Apps within Model-Driven Forms”