The Creator Kit, published by the Microsoft Power CAT team, is a collection of 24+ Fluent UI controls and templates for Power Apps makers to create delightful app experiences more rapidly.

What’s included

The Creator Kit is distributed in three managed solutions, each containing unique components:

All controls and components included in the kit use the Fluent UI framework to help easily create consistent, beautiful, and effective user experiences for custom business applications.

Creator Kit (CreatorKitCore)

A solution that contains the core components of the Creator Kit:

	Display name	Type	Status
	AutoWidthLabel	Code	Stable
	Breadcrumb	Code	Stable
	Calendar	Code	Preview
	CommandBar	Code	Preview
	ContextMenu	Code	Stable
	Dialog	Canvas	Experimental
	Elevation	Code	Stable
	ExpandMenu	Canvas	Experimental
	DetailsList	Code	Stable
	Header	Canvas	Experimental
	Icon	Code	Stable
	KeyboardShortcuts	Code	Stable
	Nav	Code	Stable
	Panel	Canvas	Experimental
	Picker	Code	Stable
	ProgressIndicator	Code	Preview
	ResizableTextArea	Code	Stable
	SearchBox	Canvas	Experimental
	Shimmer	Code	Preview
	Spinner	Code	Preview
	TagList	Code	Stable

See the control reference for all updated controls and their status.

You will notice some components are marked as preview or experimental. Preview is tagged for controls added recently, and experimental is if an underlying platform capability a component depends on is not generally available (e.g., canvas components are not supported in custom pages).

Reference Solutions

These solutions provide templates and utilities for building with Creator Kit components in canvas apps vs custom pages (embedded in Model Driven apps).

Each reference solution contains a reference application that lets you interact with each component and see the underlying formulas that render it. It’s a great way to quickly learn how the components behave and are implemented.

Real world scenarios

Custom Outlook Panel

The kit components were used created a flyout experience in the Outlook web app using the Panel, Elevation, and Icon controls. Posted by Mats Necker.

CoE Starter Kit Environment Management refresh

The Environment Creation Request experience to view a request in detail, migrated into a custom page. part of the CoE Starter Kit.

Get Started

Start using the Creator Kit by reading the setup instructions.

Support

Report bugs in our GitHub repository issues. Our team will triage issues with the Creator Kit components. See our support documentation for more guidance.

Feedback

We host our backlog in the GitHub repository to make our roadmap publicly available. We largely depend on community feedback to prioritize feature development and continued investment in the kit.

Upvote (?) backlog items you would like to see in the kit next to help our team determine the demand for each component. Work that is committed will be associated with a specific release.

You can also submit a feature request if the backlog does not have the Fluent UI components or capabilities you need.

Everyone benefits from the Creator Kit

The kit provides many improvements that affect Power Platform makers, users, and admins:

• Makers can focus efforts on building the problem-solving features of an application. The cohesive Fluent UI design makes it easier to make custom pages look more consistent and like model driven apps. You don’t need to be a front-end prodigy – or have budget for a design team – the kit will help you make stunning apps with the latest and most contemporary designs.
  
• Users will interact with the cohesive set of components that are intuitive and familiar (same controls used in all modern Microsoft applications). The components provide a performance boost which also provides a better user experience, which can help users be more productive while using your apps.
  
• Administrators who must govern UI consistency within an organization benefit from the modern theming architecture that Fluent UI provides inherently in the kit’s components. The components are developed and supported by dedicated engineering teams at Microsoft, so companies can deploy apps with Creator Kit components into production with confidence.

Additional Resources

• GitHub Repository – Master
• GitHub Repository – Code components
• User Interface Guidance Documentation
• Fluent UI Documentation

The post Introducing the Creator Kit – Efficiently create performant Fluent UI based Power Apps appeared first on Microsoft Power Platform Blog.

How you choose to use environments depends on your environment strategy and the apps you’re trying to build.  For example:

• You might have separate development, test and production environments for your business import apps.
• You might have shared environments for productivity use cases.
• You might have temporary environments to support training events or hackathons.

Developing an environment strategy will be at the core of your administration and governance considerations for the Microsoft Power Platform. Security model, data exfiltration rules, and resource allocation (such as Dataverse capacity) are all affected by how you decide to manage environments.

Limiting environment creation as part of your environment strategy is beneficial to maintain control: both to prevent unaccounted capacity consumption and to reduce the number of environments to manage. If users have to request environments from central IT, it’s easier to see what people are working on.

However, because multiple steps (such as configuring security roles and Data Loss Prevention (DLP) policies) are involved in creating and setting up environments, admins run the risk of becoming the bottleneck.

If there is no system in place to carry out environment provisioning tasks and the demand for new environments is high (for example, in a large company with many projects in their backlog), admins risk slowing down projects.

New components added to the CoE Starter Kit’s Core Solution are designed to help admins simplify and automate their environment management strategy. The components make up a request management system specifically for environment creation. It includes:

• An interface for makers (non-admins) to create new and view existing requests.
  
• An interface for admins to review and approve or reject requests.
  

• Automation of environment provisioning when a request is approved, which includes:
  • Creating the environment with the requested details
  • Provisioning the Dataverse database (if requested)
  • Granting permissions to the requested environment administrators
  • Updating the Data Loss Prevention policies to securely accommodate the new environment’s connectors (if requested)
• Automation of environment cleanup (to avoid sprawl)
• Email notifications for important request stage changes (submission, approval, fulfillment, rejection, and expiration)

Read the full environment creation request process used by the template in the documentation.

Get Started

Download and install the latest version of the Center of Excellence Starter Kit – Core Solution to access the new environment management components. Instructions: Set up the CoE Starter Kit.

To learn how to use the environment management components, go to How to use the Environment management components in the CoE Starter Kit documentation.

View the details of the new components in the Core components documentation.

Environment documentation for admins

Detailed documentation about Power Platform environments can be found here:

• Environments overview – Power Platform | Microsoft Docs

• Create and manage environments in the Power Platform admin center – Power Platform | Microsoft Docs

• Control environment creation and management – Power Platform | Microsoft Docs

• Control user access to environments: security groups and licenses – Power Platform | Microsoft Docs

• Configure user security in an environment – Power Platform | Microsoft Docs

• Establishing an Environment Strategy – Microsoft Power Platform – Power Platform | Microsoft Docs

About the CoE Starter Kit

A Microsoft Power Platform Center of Excellence (CoE) means investing in and nurturing organic growth while maintaining governance and control. A CoE is designed to drive innovation and improvement, and as a central function it can break down geographic and organizational silos. A CoE can be a powerful way for an organization to align around business goals rather than individual department metrics. A key principle is to clarify why you’re setting up a CoE, what you aim to accomplish, and the key business outcomes you hope to achieve.

The CoE Starter Kit provides some automation and tooling to help teams build monitoring and automation necessary to support a CoE. It represents what we’ve learned from some of the largest organizations implementing Microsoft Power Platform.  This tool, built with Microsoft Power Platform, is intended to be just that: a starter kit for technology to enable your processes. It can help with the how, once you’ve established the what and why.

Disclaimer

Although the underlying features and components used to build the Center of Excellence (CoE) Starter Kit (such as Dataverse and connectors) are fully supported, the kit itself represents sample implementations of these features. Our customers and community can use and customize these features to implement admin and governance capabilities in their organizations.

If you face issues with:

• Using the kit: Report your issue and feature requests here: aka.ms/coe-starter-kit-issues (Microsoft Support won’t help you with issues related to this kit, but they will help with related, underlying platform and feature issues.)

• The core features in Power Platform: Use your standard channel to contact Support.

The post Simplify environment administration in the Microsoft Power Platform with new CoE Starter Kit components for Environment Management appeared first on Microsoft Power Platform Blog.

If admins create policies that block specific connectors or disallow certain connectors to be used together, these restrictions will impact apps and flows at design and run-time.

We are excited to introduce you to the DLP Editor – a new app that is part of the Center of Excellence Starter Kit. You can use the DLP Editor to observe the impact of an existing policy or the potential impact of policy changes you’re considering.

The goal of the DLP Editor is to provide admins with a view of currently impacted apps and flows, and a view of resources that would be disabled if new or updated policies were to be enforced. The tool reads and updates DLP policies while showing a list of apps and flows that are impacted by the policy configurations.

You can use this app to:

• Review whether existing policies impact canvas apps and cloud flows in your tenant.
• Change existing DLP policies and update the connector grouping in the policy.
• See what flows or apps would be impacted by the change, before you save the policy.
• Mitigate the risk by contacting makers and informing them about the best course of action for their app or flow.

Update existing DLP policies to review the impact:

Our recommendation is to create a policy in the Power Platform Admin Center with the connector configuration that you want, don’t assign it to any environments (thus not causing an impact), then opening the DLP editor app of the CoE Starter Kit to modify the policy, assign it to the environments you want and performing an impact analysis there.

DLP documentation for admins

Detailed documentation about Power Platform DLP capabilities can be found here:

• Data loss prevention policies
• Create a DLP policy
• Manage DLP policies

Get started

Download the solution pack at aka.ms/CoEStarterKitDownload.

The DLP Editor is part of the Center of Excellence – Core Components; this documentation explains how to set up the Core Components.

CoE Starter Kit Overview

The Center of Excellence (CoE) Starter Kit is a set of templates that are designed to help you get started with developing a strategy for adopting, maintaining and supporting the Power Platform, with a focus on Power Apps and Power Automate.

Disclaimer

Although the underlying features and components used to build the Center of Excellence (CoE) Starter Kit (such as Dataverse and connectors) are fully supported, the kit itself represents sample implementations of these features. Our customers and community can use and customize these features to implement admin and governance capabilities in their organizations.

Support

If you face issues with:

• Using the kit: Report your issue here: aka.ms/coe-starter-kit-issues (Microsoft Support won’t help you with issues related to this kit, but they will help with related, underlying platform and feature issues.)
• The core features in Power Platform: Use your standard channel to contact Support.

The post New in the CoE Starter Kit: Review the impact of DLP policy changes appeared first on Microsoft Power Platform Blog.

Figure 1: Example environment strategy diagram

Developing an environment strategy means configuring environments and other layers of data security in a way that supports productive development in your organization, while securing and organizing resources. A strategy to manage environment provisioning and access, and controlling resources within them, is important to:

• Secure data and access.
• Understand how to use the default environment correctly.
• Manage the correct number of environments to avoid sprawl and conserve capacity.
• Facilitate application lifecycle management (ALM).
• Organize resources in logical partitions.
• Support operations (and helpdesk) in identifying apps that are in production by having them in dedicated environments.
• Ensure data is being stored and transmitted in acceptable geographic regions (for performance and compliance reasons).
• Ensure isolation of applications being developed.

Key take aways

Understand environments

Before we get started, let’s look at some environment and security key facts:

• Environments are tied to a geographic location that is configured at the time the environment is created.
• Environments can be used to target different audiences or for different purposes such as dev, test, and production.
• Data loss prevention (DLP) policies can be applied to individual environments or the tenant.
• Every tenant has a default environment.
• Non-default environments can be created by licensed Power Apps, Power Automate, and Dynamics 365 users. Creation can be restricted to only global and service admins via a tenant setting.
• Non-default environments offer more control around permissions.
• An environment can have one or zero Common Data Service instances.
• Environments include predefined security roles that reflect common user tasks with access levels defined to match the security best-practice goal of providing access to the minimum amount of business data required to use the app.

Types of environments

Before you get started developing an environment strategy, ensure you understand the different types of environments.

Environment security

Different personas have different levels of access, and each are represented in two different ways depending on if the environment has CDS provisioned. If the environment has CDS, permission is controlled through the Security Role model (which is a table stored in CDS). If there’s no CDS, the permissions are Azure-based role assignments.

Note on admin access: Global tenant admins, Dynamics 365 Service admins and Power Platform service admins can always view and perform administrative actions on any environment in the tenant from the admin center. Assign these roles in the Azure Portal using Privileged Identity Management (PIM).

Developing a strategy

Here is a starting point to consider for your environment strategy.

• Assign your admins the Microsoft Power Platform service admin or Dynamics 365 service admin role.
  These roles provide administrative access to Power Apps canvas apps, flows, model-driven apps, environments, custom connectors, connections, gateways, Power Apps portals, AI Builder models, and all Common Data Service instances. This role should be assigned to admins who don’t need global tenant admin access and are dedicated to managing Microsoft Power Platform.
• Restrict the creation of net-new production environments to admins.
  Limiting environment creation is beneficial to maintain control in general: both to prevent unaccounted capacity consumption and to reduce the number of environments to manage. If users have to request environments from central IT, it’s easier to see what people are working on if admins are the gatekeeper.
• Treat the default environment as a user and team productivity environment for your business groups.
  Renaming the environment through the admin center is recommended to make the purpose of that environment self-explanatory. Clearly communicate that Default is used for user and team productivity scenarios, but not business-important or mission-critical apps. This environment can’t be disabled or deleted because it hosts integration with products like SharePoint and Project. We recommend a tiered approach to user and team productivity environments.
• Establish a process for requesting access to or creation of environments.
  With environment creation locked down and default reserved for first-party integration apps, make it clear to your organization that a proper development project should be started by requesting a new dedicated environment where there is clear communication of intent and support between developers and admins. The next section has more detail about automated environment creation, which is just one way to implement an easy formal request process.
• Dev/test/production environments for specific business groups or applications.
  Having staged environments ensures that changes during development don’t break the users in production and data isn’t corrupted. When resources are limited, focus this pattern for mission-critical and important apps, or on business units that have the greatest need for their own dedicated space.
• Individual-use environments for proof of concepts and training workshops.
  To host workshops, hackathons, and internal training events—like App in a Day or Flow in a Day—create a new, separate environment for the event to keep everyone organized. Ask the users to save the resources they need in a short term after the event and clean up the environment, or reset it for other events. Use Trial environments that do not consume capacity for these types of activities.
• Establish Tenant and Environment level Data Loss Prevention (DLP) policies
  Data Loss Prevention (DLP) policies act as guardrails to help prevent users from unintentionally exposing organizational data and to protect information security in the tenant. An essential part of the Power Platform Admin role will be to establish and maintain tenant and environment level DLP policies.

Tiered approach to team and user productivity environments

Default Environment

Everyone in your tenant has permissions to create apps and flows here. There currently is no way to block the Environment Maker role assignment in this environment. This is also the environment that is used for first-party integrations, like creating an app from a SharePoint list. Learn more: The default environment

To reduce risk to data, the types of connectors used in your apps and flows should be limited to a less permissive data loss prevention (DLP) policy. This policy should cover common individual and small team productivity use cases, like working with SharePoint data, sending emails, and having an approval workflow.

Power user environment

While the default environment covers many use cases, some power users will have more advanced needs for their apps and flows, like integrating with Microsoft Teams, Azure Active Directory (Azure AD), or Azure DevOps.

For this purpose, we recommend creating a power user environment. This shared environment should use mre permissive DLP policies and admins should control the maker list to this environment.

Some considerations for the power user environment:

• Review the available connectors in this environment to make sure it’s the right fit for your users.
• Document the purpose and available connectors in this environment clearly—for example, on a SharePoint site or wiki.
• Create an automated process for makers to request access to the power user environment—for example, using Microsoft Forms, a SharePoint site, or an app. If required, this process could include approval by the line manager or IT.

Custom environments

While the shared environments cover many use cases for applications, teams and projects might benefit from having a custom environment to support their business unit-specific use cases or application lifecycle management scenarios.

Some considerations for custom environments:

• Work with the project teams or business units to establish if they require dedicated development, test, and production environments or if a dedicated development environment and shared test and production environments are more suitable to their use case.
• Consider dedicated environments for critical projects and workloads. Developers have Environment Maker access in the development environment, but only user access in the test and production environments. End users only have end user access to the production solution so no one can modify the production applications.
• Consider sharing test and production environments between important but medium complex apps. Individual projects and business units have their own development environment to protect data, but solutions are deployed to shared test and production environments. Developers are end users in the test environment, and end users only have basic user access to solutions and data in the production environment.
• Work with the business unit to establish which connectors are required and create an exception policy.
• Work with the business unit to establish who will be a maker in this environment, and who will be the environment administrator.
• Each environment consumes 1 GB of data capacity, so manage custom environments wisely.

In addition to the above recommendations, establishing your environment strategy will also shape and direct your DLP strategy.

Additional recommendations to manage environments

Based on successful experience with customer engagements, here is a list of additional recommendations that can help make managing environments easier.

• Use a service account to deploy production solutions
  Create a service account that central IT manages to deploy to test and production environments. This is beneficial for many reasons:
  • Allows all members of IT to manage admin resources (such as test and production environments).
  • Only the service account has admin permissions in the environment.
  • All other users have end user permissions and cannot create new resources—this is important because if users are given access to a data connection, they cannot create any new interface to interact with the data that wasn’t intended by the developer.
  • IT is aware of production-grade applications that are in deployment since they’re involved in the implementation.
  • Service accounts will need Microsoft Power Platform or Dynamics 365 service admin permission in PIM. Assign additional licenses as needed depending on what connectors need to be used in the request process (for example, if Common Data Service and Outlook are used, assign premium Power Apps and Office Enterprise).
  • When displaying the details for an application, it will show the service account as the creator and not the maker. This will help end users know who to contact in case of application issues.

  Consider if the risks of having a service account are important to you. Some organizations aren’t comfortable having a service account because, for example, a shared resource with admin privileges cannot be tracked to a single person. This is valid, but can be mitigated with steps such as enforcing location-based conditional access, tracking the audit logs to an IP, or more extensive methods like maintaining a secure access workstation that requires user identification during use and restricting the service account access to that device.

• Reduce the number of shared development environments
  Have separate environments for separate project development, especially when dealing with secure data. Environments are containers for resources such as connections to data, and in development environments there might be multiple people with environment maker access. If makers have access to a shared data connection and can create apps and flows, there is a risk that someone will create a new interface to read, update, and delete data they might have been given access to. This is especially important to keep in mind for the default environment—you should always have important data connections, custom connectors, and other assets that need security in isolated environments to protect them.
• Share resources with Azure AD security groups
  Security groups can be used to manage access to Power Apps, flows, Common Data Service security roles, and other Office 365 services such as SharePoint Online. This removes the admin’s burden to update access to individual end users for each component (especially if multiple are involved)—the app owners can modify that at the security group level without IT (unless IT restricts access to security group management).
• Automate environment creation
  The admin connectors (Microsoft Power Platform for Admins) make it possible to create an approval flow where users request environments when IT has restricted environment creation to admins. Central IT can review a request and approve or reject the creation of the environment, without being responsible for manually going to the admin center and creating the environment for the user, just for validating the request details, business justification, DLP requirements, and whether enough capacity is available.
• Create temporary development environments
  As mentioned, it’s recommended to separate development environments as much as possible, and specifically avoid simultaneous app development for critical solutions in the default environment. If environments are created for development purposes, put a deadline on how long the environment should be available to the developers and have a process in place to back up and remove them.
• Less is better
  Although it’s important to make sure resources are reasonably partitioned between projects and business units using environments, it’s still important to find a good balance between security and feasibility. Managing shared test and production environments is a good way to facilitate a larger number of important solutions while preserving capacity and following best practices. This maintains restricted permissions because test and production have restricted environment permissions, and therefore the end users can’t modify the applications.
• Provision environments with Common Data Service instances in the appropriate region
  In companies where employees work in multiple countries, there might be some compliance considerations in terms of where data is stored and sent between countries. If the environment has a Common Data Service instance, the data is physically being stored in the region. Review the list of supported environment regions.

Factors that influence provisioning

There are some factors that influence when to provision which types of environments:

• Defined Tiers of application support
  The level of complexity, how critical the app is, and users impacted by the application (for example, monthly active users/total users in an org) are all important measures of how to provision environments to support all the scenarios.Different types of applications should be separated in different environments based on how critical each is.Figure 2: An example of how to define types of application solutions and how they should be supported
• Capacity
  Each environment (besides trial and developer environments) will consume 1 GB to initially provision. This might be a constraint for provisioning environments if your organization doesn’t pay for premium Power Apps or Dynamics 365 licenses, and it’s also a shared capacity across the tenant needs to be allocated to those who need it.Conserve capacity by:
  • Managing shared test and production environments. Unlike shared development environments, permissions in test and production environments should be limited to end-user access for testing.
  • Automate cleanup of temporary development environments and encourage use of trial environments for testing or proof-of-concept work.
• Admin Involvement
  It’s not always possible to have central IT involved in every development project happening throughout the tenant, especially if the IT team is smaller or there’s a larger enterprise to manage.Reduce the burden on the admin by:
  • Automating environment creation so the tenant admin only needs to approve the request.
  • Automating development environment cleanup with temporary environments.

Clearly communicate your organization’s environment strategy to makers

Set up a SharePoint site or a wiki that clearly communicates:

• The purpose of your default environment.
• The purpose of shared team and user productivity environments, in addition to other shared environments makers might have access to (for example, training environments) and the process of how to request access to those environments.
• The purpose of trial environments and how to request them.
• The purpose of developer environments and how to create them
• The process of requesting custom environments for specific business unit or project purposes.
• The responsibilities of a maker:
  • Keep the tenant clean. Delete your environments, apps, and flows if they are no longer needed. Use test environments if experimenting.
  • Share wisely. Watch out for oversharing of your environments, apps, flows, and shared connections.
  • Protect organization data. Avoid moving data from highly confidential or confidential data sources to non-protected or external storage.

Also clearly communicate your organization’s DLP policies to makers.

The post Establishing an Environment Strategy for Microsoft Power Platform appeared first on Microsoft Power Platform Blog.

A Microsoft Power Platform Center of Excellence (CoE), as talked about in this blog post, refers to an entity that is responsible for nurturing the growth of Power Apps and Power Automate in their organization, while applying the right administrative guardrails.

The responsibilities of a CoE typically fall into these four buckets:

1. Administration & Governance
2. Nurture
3. Support
4. Operations

A CoE is designed to drive innovation and improvement, and through its central function can break down geographic and organizational silos in order to bring together like minded people with similar business goals to share knowledge and success, whilst at the same time providing standards, consistency, and governance to the organization.

For a more detailed explanation of the functions and best practices to establish a CoE – see the talk titled “Tried and tested techniques for establishing a CoE”, that was presented at the Microsoft Business Applications Summit in June 2019. You can download the ppt here.

As the talk lays out, a CoE could start off quite simple with a single individual using the provided tools and best practices to get a view into Power Apps activity in their organization, or may grow into a more mature investment with multiple functions and roles, such as in the case of Chevron, where they’ve established a 20+ person CoE to manage multiple aspects of governance, training, support and automated app deployment across the organization.

We would encourage the reader to understand where they are in their adoption journey and invest accordingly. A key principle is to get clear about why you’re setting up a CoE, what you aim to accomplish and the business outcomes you hope to achieve. Then get started, and learn and evolve along the way. For many, the CoE is a first step in fostering greater creativity and innovation across the organization by empowering business units to digitize and automate their business processes, while maintaining the necessary level of central oversight and governance. In its fullness, a CoE typically encompasses all the functions mentioned above, in some form.

Center of Excellence Starter Kit

The Center of Excellence (CoE) Starter Kit is a collection of templatized best practices, that are designed to help organizations get started with tools needed to set up a CoE. The kit focuses on both Administration and Governance function, as well as Nurture functions of the CoE.

The download link for the CoE package, including setup instructions, documentation  and source code can be found at the end of this blog post.

Before we dig into CoE Starter Kit features, we did want to take a slight detour to explain our philosophy around rolling out Admin & Governance features and point out where the CoE Starter Kit fits in that context.

Why the need for a CoE Starter Kit

Our Admin and Governance capabilities can be broadly categorized into three categories.

Out of the Box features:  These core capabilities for admins and makers exist in the product admin portals and are the easiest and most robust way to complete tasks. For example, Environment and DLP Policy creation can be executed in the PowerApps and Flow admin centers.

Platform extensions: There are four ‘admin connectors’ that provide access to the same APIs that the out-of-box product use. These have been exposed through the connectors library to give users the ability to create custom solutions to execute administrative or governance related tasks. Please refer to the Admin connectors blogs for details. For example, provisioning a new Environment can be automated using the admin connectors.

The use of the extensions (and templates below) represents a feedback loop, that we use to help prioritize our out of the box product admin  features.

Templates and Customization: The CoE Starter Kit falls into this category. It is a set of templates that use the admin connectors in combination with other connectors and formulas to achieve some specified goal. The nature of a template is to provide a good solution for that specific task, but it might not have the exact functionality that everyone needs and could require adjustment to achieve what others might be looking for. For example, admins could use the Environment creation template that comes with the  Starter Kit, or they can use it as a starting point and modify it as appropriate.

CoE Starter Kit Features

To delve into the administration and governance steps in more detail, watch the admin breakout sessions from the 2019 Microsoft Business Applications Summit and the Managing and supporting Power Apps and Power Automate at scale session from 2019 Ignite.

The starter kit consists of multiple tools that are designed to help facilitate some of the responsibilities of a CoE – the tools and components are split into three solutions:

1. Center of Excellence – Core Components
   These components provide the core to get started with setting up a CoE – they sync all your resources into entities and build admin apps on top of that to help you get more visibility of what apps, flows and makers are in your environment. Additionally, apps like the DLP Editor and Set New App Owner help with daily admin tasks.
   The Core Components solution only contains assets relevant to admins. No assets need to be shared with other makers or end users.
   Requirement: User(s) will require a Per User license, as well as Global or Power Platform Admin permissions

   Scenario	Toolkit component
   Catalog tenant resources	1.CDS Entities: Environments, Apps, Flows 2.Admin | Sync Template v2 (Flows) – all, Apps, Flows, Custom Connectors, Connectors, Model Driven Apps 3.Admin | Sync Audit Log (Flow) 4.Power BI Dashboard 5.Custom Connector for Office 365 Audit Logs 6.Power Platform Admin View (Model Driven App)
   DLP Strategy + Visibility	7.DLP Editor (Canvas App) 8.DLP Customizer (Canvas App)
   Change App Ownership	9.Set New App Owner (Canvas App)

2. Center of Excellence – Governance Components
   Once you are familiar with your environments and resources, you might start thinking about audit and compliance processes for your apps. You might want to gather additional information about your apps from your makers, you might want to audit specific connectors or app usage – apps like the Developer Compliance Center and flows to identify connector usage part of this solution will help with that.
   The Compliance Components solution contains assets relevant to admins and existing makers.
   The Compliance Components provide a layer on top of the Core Components, it is required to install the Core Components prior to using the Audit Components.
   License Requirement: Makers participating in the audit and compliance workflows will need a Per App or Per User License.

   Scenario	Toolkit component
   Sample Audit Process	1.Developer Compliance Center (Canvas App) 2.Flow – Compliance detail request 3.Business Process Flow for Auditing resources
   Archive unused apps	4.App Archive and Clean Up – Start Approval and Check Approval (Flows) 5.App Archive and Clean Up Admin View (Model Driven App)
   Act based on certain connector usage	6.Find and add admins as owners for apps that leverage certain connectors (Flow) 7.Find and disable flows that leverage certain connectors (Flow)

    

3. Center of Excellence – Nurture Components
   An essential part of establishing a CoE is nurturing your makers and an internal community. You will want to share best practices and templates and onboard new makers – the assets part of this solution, like the Welcome Email and Template Catalog can help develop a strategy for this motion.
   The Nurture Components solution contains assets relevant to everyone in the organisation.
   The Nurture Components provide a layer on top of the Core Components, it is required to install the Core Components prior to using the Nurture Components.
   License Requirement: Anyone in CoE community will need a Per App or Per User License.

   Scenario	Toolkit component
   Onboard new makers, provide training and share best practices	1.Admin | Welcome Email (Flow) 2.Template Catalog (Canvas App) 3.Admin | Newsletter with Product Updates (Flow) 4.Training in a day Management and Registration (Canvas Apps) 5.Training in a day Feedback Reminder, Registration Confirmation and Reminder (Flow)
   Encourage Adoption	6.App Catalog (Canvas App)

These scenarios align with real needs we observed throughout our customer interactions, and are intended to act as a starting point that should be extended.

DLP Strategy

Today, if a DLP policy is created by an admin, there is no good way of determining what apps will be affected ‘out-of-box’ in the Power Apps admin center. Although policies should definitely be put in place to increase security, implementing a policy in a tenant with existing resources risks disrupting some existing business processes. The goal of the DLP Editor canvas app is to provide admins a view of what resources will be disabled if a new or updated policy were to be enforced. Using the admin connectors, it is able to read DLP policies and details about each app’s connection references, and outputs a list of apps with connection references in opposing groups. Since the connectors also provide details about the current app owner, the app allows the user to communicate with the owner to determine the best course of action based on the requirements of the policy.

Catalog tenant resources, visualize data in Power BI

The admin centers provide a view of Power Apps and Power Automate resources in each environment to admins, but it does not have all the data listed in a tenant-wide view and there are some additional details that might be useful to display together. To make visualizing data in the tenant easier, multiple components are included to help enable such a tenant-wide view.

First, a Flow called “Admin | Sync Template” uses the admin connectors to read all data in all environments, including Power Apps, Power Automate, Connectors, Connection References and Makers. This data is stored in CDS entities that match the schema of the objects returned from the admin connectors, basically copying the data from the API. Once the data is synced, there is a master list that can be easily visualized in the provided Power BI Dashboard. Although it might be the same data that was accessible before in the admin center simply rearranged, there are many meaningful insights that can be made from this kind of command over the data in Power BI. For example, it will show the most active makers and region of makers, or most used connectors across the tenant. This detail can be useful for IT to understand which areas need more support, which might not have been easily surfaced otherwise.

Another component syncs audit log data into CDS, giving the ability to aggregate session count and monthly active users (MAU) totals for apps. This can help identify which apps need more attention; Higher usage can indicate which apps are most used and therefore more prone to affecting a potentially high critical business processes. It’s not only important to understand what apps need support, but also to keep track of how Power Apps and Power Automate resources have been increasing productivity by replacing an old or creating a new business processes.

The Power BI Dashboard is now also available via app source.

App Audit example process

In the example provided, fostering communication between the center of excellence and power users is mutually beneficial. If makers provide more information about the app, those in charge of security and support can be aware of the requirements, risks and business justification for the app. In turn, the app maker can expect a better support model for development and maintenance.

In the starter kit, the PowerApps App entity has additional fields that represent requirements from the center of excellence, which the app maker is responsible for filling out. There is a Flow that reads all the records in the PowerApps App entity, and sends a notification to the app maker if any app is not compliant with the company’s agreement policy. The threshold for determining if an app is compliant is that the maker has provided business justification requirements and the app has been published in the past 60 days. If the app is not compliant, the maker must go to the Developer Compliance Center canvas app and follow the instructions to stay compliant.

Once the business requirements are submitted and ready for review, an admin can review the details in a Power Platform Admin View model driven app. There is a view that filters out all the apps that are compliant and need final validation from an admin. On each app, there is a business process flow that is designed to guide the audit process from reviewing the details to assigning it to the app catalog.

This audit process example in the starter kit only covers PowerApps apps–can you think of a good audit process for validating Flows or Environments?

App Catalog

There are many reasons why an app catalog might be used, but the most common reason is for discoverability. Normally if an app is shared broadly, it might be difficult for some end users to find the correct environment, or dig up the share link that was initially sent out. The canvas app provides a template for displaying apps that have been marked true for ‘In App Catalog’ and ‘Featured In App Catalog’, and have a category, which are all metadata fields in the CDS PowerApps App entity. In this scenario, apps can be featured in the app catalog once they have passed the audit process. This means that not only is the app more discoverable for end users, but also ensures that the app that has been shared broadly is being monitored by some authoritative body. One example of how you can extend this canvas app is to add the ability for users to rate, comment and favorite the apps.

Welcome Email to new makers

If a new maker is detected during the Sync Template Flow, another Flow is kicked off to send a welcome email to that new maker. This scenario is important from a nurturing perspective, because it provides a proactive level of support that will foster desired practices. For example, the welcome email has the option of sharing a list of learning resources and the company’s internal Yammer channel for peer support. This makes the development experience better for the makers because they have a larger channel to seek help from, which can grow more independently and can be self sufficient. This email provides the best medium to introduce other first-time material to makers, such as links to data compliance policies and things of that nature (this is an example of a potential extension).

The solution can and should be customized in the ways that fit each unique organization. Some companies might prefer a more strict auditing process, where they decide to delete resources if not compliant. Others might prefer an even more relaxed approach that what is there. These details are unique to each organization and might not always be common. Understanding what those processes that dictate the way the Power Platform is governed is the overall requirement of the center of excellence, these tools are just means to this end.

In Part 2 of this blog post we share strategies on how to get started with adopting the CoE Starter Kit.

Download

Read the documentation to learn about all the components in the solution, the installation instructions for the solution and additional information on developing a Center of Excellence. This template is intended to represent an example tool set with extendable components, which should be customized to meet each organization’s requirements.

Directly download the solution pack at aka.ms/CoEStarterKitDownload.
View the full documentation and setup instructions at https://docs.microsoft.com/power-platform/guidance/coe/starter-kit

Disclaimer

Although the underlying features and components used to build the Center of Excellence (CoE) Starter Kit (such as Common Data Service, admin APIs, and connectors) are fully supported, the kit itself represents sample implementations of these features. Our customers and community can use and customize these features to implement admin and governance capabilities in their organizations.

If you face issues with:

• Using the kit: Report your issue here: aka.ms/coe-starter-kit-issues. (Microsoft Support won’t help you with issues related to this kit, but they will help with related, underlying platform and feature issues.)
• The core features in Power Platform: Use your standard channel to contact Support.

The post Introducing the PowerApps Center of Excellence Starter Kit appeared first on Microsoft Power Platform Blog.

This blog post is applicable to you, only if you see a “Upgrade Now” link in the Admin Center as shown in the screenshots of this blog post.

We also want to ensure that everyone understands that the data stored for the Flow Approvals feature is stored in the CDS instance in the Default Environment, and if their Default Environment has a previous version CDS instance, the tenant admin must upgrade this instance to preserve that data (Pending Approval Requests and Approval History). See the Flow Approvals documentation for more details.

Motivation

There are two main reasons to consider if your previous version of CDS instance needs to be upgraded:

1. Users are using the Flow Approvals feature

   If the organization uses the Flow Approvals feature, the data related to Flow Approvals is stored in the CDS instance of the organization’s Default Environment.  If the organization wants to preserve Flow Approvals history and Approvals currently in transit, they will need to upgrade the previous version of CDS instance in their Default Environment.

2. Users in the tenant need to preserve data in their previous version CDS instance

   If there are previous version of CDS instances with data the organization needs to preserve, these instances should be upgraded. This will usually only be possible if the users that created the database or custom tables in the database had the paid licenses or a trial paid license to use the premium CDS feature.

Understanding the role of CDS in the Default Environment

Approvals data are stored in the Default Environment’s CDS instance

It is important to understand that the Default Environment’s CDS instance is the database that stores the Flow Approvals data used throughout the entire tenant. When the first Approval request is sent on a tenant, a CDS instance is automatically provisioned in the Default Environment if one did not already exist. This is important to know because many might not have been aware of this change when using the Approvals feature, as it happens behind the scenes. If the Approvals feature is being used anywhere in the tenant, all Approvals history or currently pending Approvals data is stored in the CDS instance in the Default Environment.

If the Default Environment has a previous version of CDS instance with Approvals data and is not upgraded by the deadline, the Approvals data (history and pending Approvals data) will be deleted when the instance is deleted.

If the tenant admin decides to upgrade the Default Environment, he or she should be aware that Approvals functionality will stop during the downtime expected in step 3. Approvals history and pending Approvals will not be accessible by anyone until the migration step has completed.

Other Environments with a CDS instance do not store Approval data. Only the data that was added by the contributors will be in those instances.

Flow Approvals and licensing

Upgrade to CDS has no impact on licensing for Flow Approvals

Expectations for the Default Environment after upgrading

All users of the organization will get access to Model-driven app capabilities besides Canvas apps and Flow after upgrading the Default Environment to CDS for Apps. This does not necessarily mean they will be able to build Model-driven apps because a P2 license is required, but they can start a P2 in order to create Model-driven apps.

How Security Roles are impacted after upgrading the CDS in the Default Environment

The way database and environment permissions are managed in previous version of CDS is different than in the new CDS for Apps, so the upgrade will change how the roles are expressed. The security roles are managed in the CDS for Apps database, and requires configuration in the portal.

Here is how the security settings will migrate as part of the upgrade process:

1. In the Default Environment, all Global Tenant Admins for the Tenant will automatically have System Administrator role to the CDS for Apps database as well – see this documentation for the details about these predefined roles
2. Any Users configured as Environment Makers will be granted the following Security roles: Environment Maker & Common Data Service User roles – see this documentation for the details about these predefined roles
3. Any Users configured as Environment Admins in the Environment will be granted the System Administrator role – see the Environment permissions topic for more details
4. We don’t have the ability to configure security roles for Security Groups Hence we cannot automatically grant permissions to Security Groups in the new environment, so the administrator has to manually assign security roles to the users belonging to those security groups.

In the previous version of CDS we had the concept of Open database, where the data stored in the common data service was open to all users. For that setting, one could share apps and view data without having to worry about managing permissions to the data.

In the new CDS for Apps database, it uses role-based security model by default to secure access to the database and there is no concept similar to OPEN which everyone has access to. The Environment Maker role has no permissions to the database by default. The CDS User role can run an app in the environment and perform common tasks for the records they own (only for non-custom entities). One has to create or configure a custom security role to explicitly grant privileges to custom entities.

Deadlines and extension

If you intend to upgrade your previous version CDS database you must start the first step before March 15, 2019.

If you begin Step 1 of the upgrade before March 15, 2019 you can continue to complete the upgrade until the service is discontinued. We intend to continue the service until April 15, 2019.

If you do not begin Step 1 of the upgrade before March 15, 2019, we will disconnect your database and store your data for 30 days before deleting it. If you wish to reconnect a database, you must contact support before March 29, 2019.

If this data does not need to be preserved past the migration deadline, it’s safe to ignore the upgrade warnings and let the CDS instance get deleted automatically.

Once the database is migrated (or deleted automatically), Flow Approvals will work normally. When the first Approval request is sent on a tenant, a new CDS for Apps instance will be automatically provisioned in the Default Environment if one did not already exist.

Other resources

For more detailed information on how to upgrade a previous version of CDS instance, see the documentation here.

The post Remember to upgrade your previous version CDS database to preserve Flow Approvals history or entity data appeared first on Microsoft Power Platform Blog.

Each script below allows you to retrieve a particular filtered set of PowerApps and Flows and outputs a list of matching records in a .CSV file. Each record represents the feature used (e.g. custom connector) and includes details such as the App ID, owner of the app, etc.

Install the modules

To use the PowerApps and Flow cmdlets, follow the installation instructions on the PowerApps cmdlet documentation page.

Run the scripts

Once the modules are installed, follow these instructions to run the scripts provided below. If you receive a security warning, you may need to unblock running the downloaded script, see this article for more details.

1. Download the desired script.
2. Run PowerShell as an administrator and make sure you’re in the same directory as the script.
3. Run the script by typing out the name

   .\findFlowsWithHttpAction.ps1

4. Each of these scripts have optional parameters to specify the Environment (EnvironmentName) or the output file path name (Path).

   .\findFlowsWithHttpAction.ps1 -EnvironmentName 820d6103-3f73-4107-a1b2-3449a98f5049 -Path ./myFlowsWithHttp.csv

Scripts

The scripts are designed to output a list of records in a .CSV file that will be created in the same directory as the script, unless specified otherwise. Each record represents a feature, so if there are multiple features in a single PowerApp or Flow, there will be multiple records (e.g., a Flow that uses a custom connector and Http action will have two records for the same Flow).

PowerApps with Custom Connectors

Lists connections to custom connectors being used in a PowerApp.

Download

PowerApps with Premium Connectors

Lists connections to premium connectors being used in a PowerApp.

Download

PowerApps with on Prem Connectors using Data Gateway

Lists connections to an On Premise gateway being used in a PowerApp.

Download

PowerApps used as SharePoint custom forms

List PowerApps that are used as custom forms in the SharePoint List experience.

Download

Flows with HTTP Actions

Lists Flows that use the HTTP request action.

Download

Flows with Custom Connectors

Lists connections to custom connectors being used in a Flow.

Download

Check back as we plan to add to this list!

Updates

• 2019-03-12: Added 3 scripts: one to discover SharePoint custom form PowerApps, one for managing trial environments, and one for managing trial licences (contributed by Steve Jeffery)

The post PowerShell scripts to discover and manage specific features in the Power Platform appeared first on Microsoft Power Platform Blog.

In PowerApps, you can implement the same concept by providing it as a front end to any data source, with the ability to customize it even more.

Scenario

A small business owner has a catalog of product information that is updated each time she gets a new shipment. Needing to input every item herself, these logging processes can be time-consuming, and sometimes error-prone. She builds a quick PowerApp that can log new items and change item data in line on the same screen, directly to the data source. With this app, she can interact with the data in the database quickly without having to connect through a separate interface, and she can include other important data and functions in the same application to host everything in the same space.

Implementation

Components

• A data source (this example uses the Common Data Service)

• Form – used for new items

• Gallery – used to display existing items and

• Text input controls – used to update existing items
   

Step 1: Add a data source

• Go to View > Data sources

• Add an existing connection or create a new one to the desired data source

• View documentation on adding data sources in canvas apps

   

Step 2: Set up a form control

This step adds a form control to add new items.

• Insert a new Form control by clicking Insert > Forms > Edit Form

• In the flyout, connect the data source to the one you just connected to, or manually update the DataSource property in the formula bar.
  

• Change the Form.DisplayMode property to New (or FormMode.New)

• Make sure to add a button to submit the form – Button.OnSelect = NewForm(Form)

• See additional documentation on the form control here

   

Step 3: Set up the gallery

To edit items in-line, insert a gallery control with text input boxes.

• Insert a new gallery – Insert > Gallery > Blank vertical

• In the template, add a text input for each field in the table you want to be able to edit – Insert > Text > Text input

• For each text input box:

  • Set TextInput.Default = ThisItem.<fieldName>
    

  • Set TextInput.OnChange = Patch(Products, ThisItem, { <fieldName>: TextInput.Text })
    

     

Step 4: Toggle the display mode (optional)

In some cases it is a good idea to disable the gallery until the user specifies they want to update the data.

• Add an ‘edit’ icon and set the following:

  • icon.OnSelect = Set(galleryDisplayMode = DisplayMode.Edit)

  • icon.Visible = galleryDisplayMode = DisplayMode.Disabled

• Add a ‘stop edit’ icon and set the following

  • icon.OnSelect = Set(galleryDisplayMode = DisplayMode.Disabled)

  • icon.Visible = galleryDisplayMode = DisplayMode.Edit

• Update the following properties:

  • Gallery.DisplayMode = galleryDisplayMode

  • Screen.OnStart = Set(galleryDisplayMode, DisplayMode.Disabled)

     

Example resources

​You can download the PowerApp and CDS Products entity schema shown in the blog here. If you use the accompanying CDS entity, import the solution to add it to your Environment with a CDS 2.0 instance.

• Import the CDS entity ‘Products’

  • by going to https://web.powerapps.com/ > [Gear icon in top right] > Advanced customizations > All solutions

  • Click on Import, upload the ProductSchema.zip file in the dialog window, then click Import

  • Select Publish all customizations, then Close the window when complete.

• Import the PowerApp to the same Environment

  • by going to https://web.powerapps.com/ > Apps > Import app (preview)

  • Select the ProductCatalogApp.zip

The post Editable Tables appeared first on Microsoft Power Platform Blog.

About

Similar to the PowerShell cmdlets for PowerApps, we have exposed the Power Platform APIs as Standard Connectors so you can more easily interact with PowerApps and Flow resources within PowerApps and Flow. To add these Connectors to your project, search for them like any Connector either in a Canvas App, or add an action in Flow.

The Admin Connectors (Powerplatform for Admins, Microsoft Flow for Admins and PowerApps for Admins) will give the user access to resources tenant-wide, whereas the Maker Connector (PowerApps for App Makers) only gives access to the resources if the user has some ownership of the resource (e.g., Owner, Editor, Shared with, etc.).

Prerequisites

Any user with a valid PowerApps license can create a connection to the PowerApps for App Makers Connector.

Creating a connection to Powerplatform for Admins, Microsoft Flow for Admins and PowerApps for Admins Connectors requires the following to work properly. Anyone can create a Connection to the admin Connectors, but will hit an error if they don’t have the correct license.

• A paid PowerApps Plan 2 license or a PowerApps Plan 2 trial license. You can sign-up for a 30-day trial license at https://web.powerapps.com/trial. Trial licenses can be renewed if they’ve expired.
• Office 365 Global Administrator or Azure Active Directory Global Administrator permissions if you need to search through another user’s resources. (Note that Environment Admins only have access to those environments and environment resources for which they have permissions, and global admins can see all resources across the tenant.)

Connector Browser tool

Use this PowerApp that acts as an Connector Browser to test out these Connectors. The purpose of this app is to make it easier to understand how to use each operation. All methods available in the Connectors are implemented and ready for use. Read through the provided definitions and example images to see how to implement these operations.

Download the Connector Browser tool export package here and import it into your Environment.

To run the operations, choose one of the connector functions on the left side of the screen, make sure all input parameters have values, and click the submit button. To view the implementations, open the tool in the studio and view the OnSelect property of the ‘SUBMIT’ button that runs the operations. Read the descriptions and look at the images provided by clicking the camera button on the right hand side of the description panel.

Example Scenario: Scheduled Flow to Get list of new PowerApps and Flows

A new Flow template using the admin Connectors is also new available. Use this template to generate reports of new PowerApps, Flows and Connectors that have been created over a specified time interval.

You can find the template here.

Connectors and Operations

Power Platform for Admins

Microsoft Flow for Admins

PowerApps for Admins

PowerApps for App Makers

Known Issues

Limitation on page size

Some operations that return a large payload of items will be paged, so not all items are returned on the first request. To get the next page requires a skiptoken from the nextLink field if it’s provided in the response (example implantation provided in the API Browser below). Here are the operations affected by this:

• Power Platform for Admins / Get-AdminEnvironment (page size: 15)
• PowerApps for Admins / Get-AdminApps (page size: 100)

The post Announcing new Admin and Maker Connectors for PowerApps and Flow appeared first on Microsoft Power Platform Blog.

Motivation

Adding a progress indicator makes for a great user experience because they break down an overwhelming amount of information into easy to consume chunks. This post will explain when to use and how to create a progress indicator as well as provide an example to download for reuse.

A common business scenario where a progress indicator is of great use is a Sign-in app. Let’s imagine a company named Contoso wants to free up the time of a front desk admin who spends a wearisome amount of time signing guests in… typically there can be a long back and forth with the visitor and admin about the spelling of the guest’s name, “Was that Veronika with a K or Veronica with a C?”. Or perhaps multiple requests to re-take their picture because their eyes were closed. This can end up taking more time than needed which makes an application built on PowerApps an amazingly efficient solution.

The Sign-in application within this blog post breaks down the process into 4 chunks that are displayed with the assistance of a progress indicator:

1. Complete form
2. Take picture
3. Confirm picture
4. Agree to terms

You may be asking yourself, “Why was the information broken down like that?”. I could have easily displayed everything within one scrolling screen and accomplished the same thing, right?

Well, not exactly… Many users will abandon a form if it is too lengthy or indirect; this is why progress indicators are advised. The indicator enables the end user to know exactly where they are at within a step-by-step process. It provides expectations to the end user so that they know exactly where they are and how many steps they have left – no guessing or assuming anything.

Example: Contoso Sign-in Form

Break-down of information

I broke down the information by dividing the screens into tasks that the user must accomplish to reach their end goal (the goal being to complete the sign-in process to enter the building).

Note: on the Complete Form screen (displayed above), the user is only prompted to fill out a form and provide a signature. I could have allowed the user to agree to the terms and conditions at the same time, however I chose not to do that because this screen is dedicated to filling out a form – not reviewing documents.

By separating the information into different screens, I am focusing the user’s attention on a single task. I want the user to fully understand what they agreeing to and by dedicating an entire screen to that task I am communicating to the end user that this is an important task that they should focus their attention on.

The progress indicator, shown in the image below, also serves as a visual indication of where the user is at within the sign-in process.

Note: the colored green circle with label control underneath saying, “COMPLETE FORM” in a Semibold FontWeight. You may have noticed all of the other circles are colored gray with a FontWeight of Normal. These visual cues all help the user understand that they have 4 steps in total.

The user can clearly understand that they are currently on the COMPLETE FORM step and know they need to complete three more steps to finish the sign-in process.

The next step prompts the user to take their picture, note the progress indicator’s appearance has changed. The COMPLETE FORM circle and text has changed color to a dull green along with the FontWeight revised back to normal. These visual changes alert the user that the tasks within that previous screen is complete and lets the user know they currently on a different screen accomplishing a different task. That task being to take a picture to continue the sign-in process.

The take picture step has been separated from the confirm picture step in an effort to simplify the process. Separating the two screens allows the user to focus on taking the picture – the OnSelect of the camera preview will capture the image and the application will automatically navigate the user to the next screen so they may confirm the picture.

If the user is unsatisfied with the picture they may press the back button and retake their picture. However, if they are satisfied with their picture they may proceed by pressing the Next button.

Once the user has completed all of the steps, they are brought to another screen that prompts them to agree to the terms and conditions of that particular company. They user presses on the checkbox to confirm they have read through everything and can press Agree to finish up the sign-in process.

The user will then be prompted with a dialog that lets the user know they have completed the sign-in process.

Implementation

The following section will explain how to design the tabular data and controls that visualize state of the progress indicator.

Controlled status color table

To create this visual appearance of the progress indicators, use tabular data (a Collection with multiple columns) to control the visual properties of the progress indicator. To do this, define the circle states: “Not started”, “In progress”, and “Complete”, in a Collection named “StatusColors”.

With this table, the controls we use to display the progress only need to look up values in this table based on status values we will define. This makes design changes later on easier, because you only need to make changes to this table and not each individual control property.

ClearCollect(StatusColors, {
     Status:”Not started”,
     Fill: RGBA(166, 166, 166, 1),
     BorderColor: RGBA(205, 205, 205, 1),
     Color: RGBA(166, 166, 166, 1)
}, {
     Status:”In progress”,
     Fill: RGBA(182, 221, 190, 1),
     BorderColor: RGBA(123, 183, 135, 1),
     Color: RGBA(123, 183, 135, 1)
}, {
     Status:”Complete”,
     Fill: RGBA(85, 199, 112, 1),
     BorderColor: RGBA(11, 142, 30, 1),
     Color: RGBA(11, 142, 30, 1)
});

Note: This collection is defined in the OnStart property, which means it will be initialized before the user can see any of the screens.

Form status table

The state of each page of the form is stored in a Collection as well. This means that the competition state of a page can generate visuals set to specific controls, and the visuals are determined by matching the page’s status to the Status field we defined in the StatusColors Collection. The blank form Collection, called “FormPageStatus”, is also generated in the OnStart property of the application, and is defined below

ClearCollect(FormPageStatus,
     {Page: 1, Screen: VisitorSignIn, Name: “COMPLETE FORM”, Icon: CompleteFormIcon, Status: “Not started”},
     {Page: 2, Screen: TakePicture, Name:” TAKE PICTURE”, Icon: CameraIcon, Status: “Not started”},
     {Page: 3, Screen: ConfirmPicture, Name: “CONFIRM PICTURE”, Icon: SmileyIcon, Status: “Not started”},
     {Page: 4, Screen: AgreeToTerms, Name: “AGREE TO TERMS”, Icon: AgreementIcon, Status: “Not started”}
)

Note: the values in the Icon attribute are the names of media assets we have uploaded to the example PowerApp.

Designing the progress indicator control

Display the collection in a gallery. Insert a new blank horizontal gallery into the screen.

Select the gallery and set the Items property of the gallery to FormPageStatus. You can edit the data source of a gallery by clicking on the purple value of the “Data” option in the right-hand “Properties” panel.

Click into the gallery template (the first box) and insert a label. The Text property of the label should automatically change to the Name field (or ThisItem.Name), which we decided represents the name of the form stage.

The gallery will display the status of the form stages with color. Insert a circle icon into the gallery template and change the Fill property to: LookUp(StatusColors, Status=ThisItem.Status).Fill . Change the BorderColor property of the circle to LookUp(StatusColors, Status=ThisItem.Status).BorderColor .

We can indicate which screen the user is on by changing the font weight to bold, based on the App.ActiveScreen value: If(ThisItem.Screen = App.ActiveScreen, Bold, Normal)

To provide a visual for each stage, we have Icon as an attribute in the FormPageStatus collection. Here we added an Image control and set the Image property to ThisItem.Icon:

Once the gallery is formatted, copy and paste the gallery to each screen where you want to display the status. In this example, the progress indicator is displayed on all screens. Make sure the X and Y values of the progress indicator gallery are the same for each copy, otherwise it will appear to jump around the screen between pages.

Updating the form status

Now that we have the data and controls to display the status set up, we need to write actions that indicate when the status should be updated. For example, when you enter a screen in the form where the status was set to “Not started”, it needs to update the status to “In Progress”. Here is what we put on the OnVisible property of every screen:

Here is what is happening in this set of statements:

1. The Set() function set the global variable CurrentPage to the record in our collection FormPageStatus that matches the active page. Saving the current page’s record into a variable makes it easier to access that record in the data set, which is done in the second statement.
2. If the Status attribute of the CurrentPage variable is not equal to “Complete”, the status will get updated to “In Progress”. This lets the user see that they have visited a page but not completed that part of the form. If the part of the form was already completed, then the status will remain complete.
3. In the Patch() statement, the first argument is the data source (the collection called FormPageStatus). The second argument is a reference to the record in curly brackets. The final argument in curly brackets is the updated value for the Status attribute.

To change the status to complete, the operation is the same except the status value is changed to “Complete”:

You would place this statement on some event that would signify that the form step is done. For example, you might want to place it on a “Next” button, and after the status changes you can navigate to the next screen in the form process.

In this example shown above, we have an If() statement that validates the form fields are filled out correctly. If they are, then the Patch() statement runs to change the first page’s status to complete. Finally, the application navigates to the next screen (in this case, to the screen TakePicture).

On the next page, the status of the first screen (COMPLETE FORM) turns to a dark green color, in contrast to the pale green color of the current page’s status (TAKE PICTURE). Recall that all we needed to do was copy and paste the gallery to each page, and the visuals are updated with the Patch statements. Since each gallery is simply reading from the same global data source (FormPageStatus), all we need to do now is indicate when and where the status should be updated. The controls and code needed to modify the visuals are all the same.

From here, all that is needed is to place the update statements in the appropriate action properties. At the end of the form you might want to refresh all the data if it’s a kiosk type app that will need to be re-used in the same session. You can do that by using the same ClearCollect() statement you used to initialize the FormPageStatus in the OnStart property of the application.

Download an export of this template here.

The post Progress Indicator with Tabular Data appeared first on Microsoft Power Platform Blog.