Microsoft Technologies leveraged on projects

One of the reasons I persist with the Microsoft Technology stack is that having a huge box of legos to build business applications with is just hard to beat. 

Microsoft tends to change names, debate branding and overall try to communicate what a consultant can bring to the table, but in most of my projects now we tap into numerous different offerings.

Take for instance my last project. In my last project we delivered an integrated model that included 

  • Microsoft Dynamics 365 Customer Engagement (Model Driven Power App + Microsoft Canvas App)
  • Microsoft Dynamics 365 Finance and Operations (Supply Chain Management focused)
  • Power Automate (Flow) (Approvals and Standard)
  • Power Portal (now called Power Pages)
  • Microsoft Dual Write (connecting DYN365FO + DYN365CE)
  • Microsoft Azure Synapse
  • Microsoft Azure Function Apps
  • Microsoft Azure Logic Apps
  • Microsoft Azure Service Bus 
  • Microsoft Teams
  • Microsoft Azure Blob Storage
  • and Microsoft Office 365 

We also coordinated the team and the application lifecycle management using Microsoft Azure DevOps, Microsoft Azure CLI, Microsoft Visual Studio, Microsoft RSAT (Regression Suite Automation Tool) and Microsoft Teams. 

Now you would think that you would need a HUGE team to deliver the above, but we actually delivered using a very reasonably sized team with a mix of resources. 

One of the beauties of the Microsoft stack of applications and offerings is that there is so much that you can do! The ability to use a platform that grows organically (SaaS) and through phased projects aligned to key business needs, keeps companies current with the latest and greatest technology offerings. 

The world moves so fast. It is great to have structures in place that allow teams to move at the same speed. 

 


Incredible Flexibility

I am working with some incredible technologies, and I am working with the Power Platform and so many cool things that can be done with this incredible engine of growth. 

Consider this: You have an incredible repository of many different data sources. You have an entire team of people who work on "DATA" (and AI and all the cool new in the data space), but you also use one or many of the Power Platform, Model Driven, Dynamics PowerApps (Sales, Field Service, Customer Service, Connected Field Service, Marketing, Talent, Custom and so many more)

Did you know that you can work with a Power BI team to create incredible reports off of your data "repositories" (pulling data from many different places) AND you can then embed these Power BI reports in a Power Platform, Power Portal. Why use a Power Portal over a custom web page or some other option? well there is that little gem of application and/or data access security. Yes, the templates are also incredibly nice, but where Microsoft shines is in the layers of awesome. 

One of the reasons that I continue to focus and grow within the Power Platform is the huge flexibility and pivoting of new technologies to meet the demanding business needs. These needs are met leveraging the same platform and the platform continues to grow and be supported. 

 


One Why | Model Driven Apps | Configurable Role Based Entitlement Security | Who gets to access What

1) Business Unit Hierarchy | The ability to divide the data into isolated silos with bridges of controlled access aligned to the defined.(Security + Performance)

2) Out of the Box Entities | The configuration of entity permissions when the entity is doing backend functionality for the system and not something such as Account, Contact....

3) Management Hierarchy | The ability to give permissions to a manager based on the permissions and data and functions that their child team member has access to.

4) Field Level Security | The ability to mask, encrypt and control who can see a specific field within an entity

5) Entity Security | The ability to control who can Create, Update, Read, Delete, Append, Append to and Share specific out of the box entities or custom entities by Organization, Business Unit, Business Unit Hierarchy or User Ownership. 

6) Flow Context | The ability to control what permissions a flow runs under, either Contextual User or a Defined User such as a system account.

AND there is more so when considering "Building Your Own", consider if you want to recreate the concept of Role Based Entitlement 

  


Getting Started with the Power Platform : A new Offering from Julie Yack

If you really like some hands on virtual training and your are ramping up your team, then  you might want to know about this new offering from Julie Yack, MVP. She really does offer some interesting training using a variety of learning techniques. Techniques that help you remember and retain. 
 
"If you are looking for an entry point for learning the Power Platform…

If SharePoint has been your only data source so far…

If you’ve made canvas apps, but never a model-driven app…

This is the course for you! In this hands on lab based course you will learn model-driven essentials and build a fully functional custom model-driven app. You will build out the data model, user experience, form automation and process automation.

And there’s puppies.

Seriously, the app you are building is for a doggie daycare.

#powerplatform #powerapps
 

Infrastructure: Forests, Tenants, Orgs, Environments, Software as a Service, Infrastructure as a service .. the Vocabulary noise is high

In case the world wasn't confusing enough we have new vocabulary and technical terms expanding at an ever increasing pace in the world of the Cloud. 

This causes even more noise when you start talking about Software as a Service and empowering the business user with their own "environment" or offering them a shared environment or simply adding to the default environment. 

What is an Environment

"Each [Power Platform] environment is created under an Azure AD tenant, and its resources can only be accessed by users within that tenant. An environment is also bound to a geographic location, like the US. When you create an app in an environment, that app is routed to only data centers in that geographic location. Any items that you create in that environment (including connections, gateways, flows using Microsoft Power Automate, and more) are also bound to their environment’s location." https://docs.microsoft.com/en-us/power-platform/admin/environments-overview

Now come to the table with the perspective of Azure IaaS,  Infrastructure as a Service. A technical team that has numerous Azure VMs and an IaaS footprint. How do they add Software as a Service to their world and include connection between their new SaaS environment(s) and their existing IaaS environments?

In the world of IaaS on Azure you have access to the Azure Resource Manager and Administrator portal.

What is the Azure Resource Manager? "Azure Resource Manager is the deployment and management service for Azure. It provides a management layer that enables you to create, update, and delete resources in your Azure subscription. You use management features, like access control, locks, and tags, to secure and organize your resources after deployment." https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview

In the world of SaaS the resourcing of azure is managed by the SaaS offering. 

In the Power Platform world we access most of the Azure management through the new Administrator Portal on Azure found at https://admin.powerplatform.microsoft.com or through each of the individual component/module administrator centers (https://admin.powerapps.com/environments, https://admin.flow.microsoft.com/environments, etc.)

 What is an Azure Forest? 

"A forest contains domains, and domains contain other types of objects. This reference architecture creates an AD DS forest in Azure with a one-way outgoing trust relationship with an on-premises domain. The forest in Azure contains a domain that does not exist on-premises. Because of the trust relationship, logons made against on-premises domains can be trusted for access to resources in the separate Azure domain."

SO when working with IaaS and SaaS it is helpful if you get them configured in the same domain.

What is an Azure Domain?  

"Azure AD DS integrates with your existing Azure AD tenant, which makes it possible for users to sign in using their existing credentials. You can also use existing groups and user accounts to secure access to resources, which provides a smoother lift-and-shift of on-premises resources to Azure.

Azure AD DS replicates identity information from Azure AD, so works with Azure AD tenants that are cloud-only, or synchronized with an on-premises Active Directory Domain Services (AD DS) environment. The same set of Azure AD DS features exist for both environments.

  • If you have an existing on-premises AD DS environment, you can synchronize user account information to provide a consistent identity for users.
  • For cloud-only environments, you don't need a traditional on-premises AD DS environment to use the centralized identity services of Azure AD DS."

 

How about that! 

Software as a Service = An application or set of applications that is hosted (such as hosted on Azure) as a software offering. The infrastructure and hosting is mostly managed by the SaaS company. 

"Software as a service (SaaS /sæs/[1]) is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. It is sometimes referred to as "on-demand software", and was formerly referred to as "software plus services" by Microsoft.[2] "

Infrastructure as a Service = A hosted infrastructure (such as a domain in an Azure Data Center) where a company might have many services, virtual machines, and other functions, but most is managed by the purchasing company.

"Infrastructure as a service (IaaS) is an instant computing infrastructure, provisioned and managed over the internet. It’s one of the four types of cloud services, along with software as a service (SaaS), platform as a service (PaaS), and serverless.

IaaS quickly scales up and down with demand, letting you pay only for what you use. It helps you avoid the expense and complexity of buying and managing your own physical servers and other datacenter infrastructure. Each resource is offered as a separate service component, and you only need to rent a particular one for as long as you need it. A cloud computing service provider, such as Azure, manages the infrastructure, while you purchase, install, configure, and manage your own software—operating systems, middleware, and applications." https://azure.microsoft.com/en-us/overview/what-is-iaas/

Org or Organization = An individual instance of a Dynamics 365 for CE database


No Code, Low Code, Extend: PowerApps and MS Flow

If you have not heard about PowerApps, Microsoft Flow, the Common Data Model (CDM) and Common Data Service (CDS) then it is time for a bit of reading. Imagine an explosion within the world of Microsoft Technology where the entire Microsoft Stack of Applications become your tool set. OH Wait, the explosion continues and pulls in 100s of other non-Microsoft applications as well.

Now you get it.

What adds an interesting twist is this concept of "No Code" so business users can now put together building blocks to deliver their own mobile applications without having to jump into the world of GitHub or Visual Studio or pick your language of choice.

Developers, don't freak out, you are still loved and needed.

The grey area becomes the space where a relatively simple business user story, is not necessarily easy from a PowerApps or Microsoft Flow delivery. This is where understanding the fits and gaps is important.

Fits - Everything can be done with no code.

Gaps - Everything can be done with no code or low code 

Big Gaps - Everything can be done with no code, low code and an extension.

So what does this really mean? 

 

 


Common Data Service - Data "un" Limits

I was having an interesting conversation the other day about some of the configuration and customization we have seen on the Dynamics 365 Platform. The conversation mentioned an example where the total number of fields added to one entity was rather significantly large. While catching up on the training in the new Microsoft Learn environment I found this statement and thought it might be a good one to share. 

"Maximum Number of fields in an entity:" REFERENCED From

  • "There is no hard upper limit on the number of fields that you can have in an entity, but there is an upper boundary due to limits in how much data you can store in a single record. It is difficult to provide a specific number because each type of field can use a different amount of space. The upper limit depends on the total space that is used by all the fields for the entity.

  • As a rule, you should have less than a few hundred fields in an entity. If you have more than a few hundred fields in an entity, then you should look at restructuring how you have designed the entities in your solutions and try to split the entity with an excessive number of fields into more than one entity." Referenced from 

 

One last note : In the world of technology everything changes so before you groan or run around and tell your friends about this. Tomorrow it could all be different. This is the beauty of Azure! 


D365 Online and Azure Logic Apps: Just a Few Basics

Definition:  "Azure Logic Apps gives you pre-built components to connect to hundreds of services." Reference Logic Apps can be used to automate business process and to schedule key steps within processes to occur at key times or when certain conditions are met. 

Logic Apps can combine predefined existing services or components or they allow you to create your own components or services. 

Logic Apps work with "Connectors". A connector uses the external service's REST or SOAP API to connect components or services. For instance a connector can call a service's underlying API. There are existing connectors such as a Twitter Connector or a D365 Connector and custom connectors can be created. 

Why would Logic Apps be considered in the world of D365 Online? 

Take for instance the need to batch process data within a time frame such as every day at 4pm process data from System A, clean the data and push it into a D365 Online Instance.  In this particular example Logic Apps can be used to bridge the need to schedule a process from an external system into D365. 

There are many other examples as well. 

You also have the ability to work with TRIGGERS and ACTIONS within the world of Logic Apps. 

  • "A trigger is an event that occurs when a specific set of conditions is satisfied. Triggers activate automatically when conditions are met. For example, when a timer expires or data becomes available.

  • An action is an operation that executes a task in your business process. Actions run when a trigger activates or another action completes."  Reference

 

Defining Triggers and actions and creating your Logic App is all done within the Logic Apps Designer. A graphical tool for creating your Logic Apps workflows. 

Logic Apps are not always the answer, but are one of the many choices in the world of Microsoft Azure and Microsoft Dynamics 365 for Customer Engagement. Take a minute to read up on Logic Apps using the reference links above. Also for a quick peek into when to use Logic Apps,  here is the decision tree. Reference

When to Use Logic Apps