Forem: Fernanda Ek

Controlling data visibility & access with RLS & OLS in Dataverse

Fernanda Ek — Wed, 10 Sep 2025 10:25:40 +0000

When we build apps with Dataverse, it’s not enough to just decide who gets access. We also need to control what data each person can actually see. Two key governance practices that help achieve this are:

Row Level Security (RLS): Decides which records a user can see. For example, an employee only sees their own record, a manager sees their department's records and HR sees everyone's.
Object Level Security (OLS): Decides which tables or fields a user can see. For example, only HR should see the 'Salary'-column, while for everyone else it's completely hidden.

By combining the two, we make sure people only see the data that’s relevant to them. It keeps sensitive information safe and avoids unnecessary exposure.

Concepts in Dataverse

RLS: Controls which records (rows) a user can see.
Implemented via Security Roles and Hierarchical Security.

OLS: Controls which tables (entities) and columns (fields) a user can see.
Implemented via Table permissions and Field-Level Security Profiles.

Scenario

You’re building an HR app in Power Apps using Dataverse with the following tables:

Employees (EmployeeID, Name, Department, Salary, Manager, etc)
Departments (DepartmentID, DepartmentName, ManagerID, etc)

Rules:

Regular employees should see only their own record.
Managers should see employees in their department.
HR staff should see all employees + Salary field.
Non-HR users should never see Salary at all.

Setting up Row Level Security (RLS)

Go to Power Platform Admin Center > Select the environment > User + permissions > Security roles
Create 3 roles: Employee Role, Manager Role and HR Role

Permissions

None = No access
User = Access only to records the user owns
Business Unit = Access to records in the same BU
Parent: Child BU = Access to their BU + child BUs
Organization = Full access

Select the 'Employees'-table and set 'Read'-permission to 'User' and save. This means the user can only see rows they own.

For the Manager Role set 'Read'-permission to Business Unit and save. Managers will see records in their own business unit.

For HR Role set 'Read'-permission to Organization (full access).

Give broader rights (Create, Write, Delete, etc) if HR should manage all employee records.

Assign roles to users

Go back to 'Settings' in the admin center and under User + Permissions select 'Users'

Select a user and select 'Manage security roles'. Now sdd the role that match their job (Employee, Manager, HR). Hit save.

Result

Regular employees only see their own record.
Managers see employees in their BU.
HR sees all employees.

Setting up Object Level Security (OLS)

We want to hide Salary from everyone except HR.

Go back to settings and select 'Column security profiles'

Add a New Profile:

Add users or teams:

Enable Field security

Go to the 'Employee'-table > select 'Salary'-column > set Field security/Enable column security = Enabled

Now, only users in a Field Security Profile can see/edit it.

Meaning, for everyone else (not in the 'HR Sensitive Data Access'-profile) they automatically get No access. Salary will be hidden from forms, views and apps.

Result

HR Role + HR Sensitive Data Access profile = full visibility of Salary.
Everyone else = cannot even see the column, it’s completely hidden in Dataverse, model-driven apps, and API queries.

Best Practices

Plan roles up front: Align with business rules before implementing.

Use security groups: Easier than managing individuals.

Test: Use 'View as role' or test accounts.

Least privilege principle: Give only the minimum data visibility needed.

Document roles: For governance, always keep a map of roles and it's permissions.

Environment variable management with Power Automate

Fernanda Ek — Wed, 06 Aug 2025 09:08:00 +0000

This is one of those tweaks I’ve been using for while, but it never occurred to me how useful it actually is until a colleague recently asked me about it.

He basically was concerned about having to update variables and store them temporally while also passing the current value into multiple flows, since the value changes dynamically. You know, create a new column(our case) just for that purpose (store temporally values) is just not elegant. On top of that, you still have to keep track of the values, know where they are being used and hope you’re not messing up the current value 😩

So, here it is, a quick walkthrough on how to build a Power Automate flow that takes care of environment variable updates for you.

Scenario: Dynamic file path for File System connector

Here is the exact scenario that got me writing this post. In one my solutions, I'm creating files locally. Nothing fancy, I'm using the File System connector and a regular "Create file"-action but the annoying part is that the path where the file gets saved is dynamic and changes depending on the conditional logic I'm using in the flow. Later, I also need to reuse the same value across multiple flows.

That’s when I decided to store the file path in an environment variable instead.

...Then, automatically update it depending on the audience. No more errors caused by hardcoded values.

Behind the scenes

When we create environment variables in Power Platform, they're stored in Dataverse across two places/entities.

Environment Variable Definitions: these where the variables name are stored.
Environment Variable Values: Here is stored the actual value.

Here's how we make it work

Our flow will:

Look for the definition based on the schema name
Check if there is already a value saved
Update it or create a new one

Start by creating the environment variable:

I'm manually running this flow, so, in my case, I'm using the instant trigger.

Add one more action "List rows" and select the "Environment Variable Values"-table.

Filter rows: Filter the records to locate the exact environment variable using this query:
EnvironmentVariableDefinitionId/schemaname eq 'YOUR_ENV.VARIABLE'

Note: Use the schema name not the display name
Tip: You can get the list of rows by running the flow once and checking the output of the action.

In my case, I added a switch control to handle different audiences. The value is passed in the trigger.

Each case inside the Switch updates the environment variable with the correct value for that specific audience.

Below, I'm using "Update a row"-action to update the value of the environment variable without to manually change values each time.

Voilà

The first compose shows the current value of the environment variable.
Then the flow runs the update action to change it.
Finally, the second compose confirms the new value was applied.

Conclusion

Honestly, this little trick has saved me so much time. Updating environment variables might not sound like a big deal, but when you are working with multiple flows, specially when you need to pass values like endpoint, target audience or other dynamic data, it really helps. Instead of creating workaround columns or hardcoding values, Environment variables makes everything cleaner and way easier to maintain.

Save it for later, you might run into a moment where this comes in handy.

How to create Generative Pages in Power Apps

Fernanda Ek — Wed, 30 Jul 2025 12:40:03 +0000

Yeees! It's finally happening and I couldn't be more excited

I've been dreaming of a day when we could describe an app and voilà, it appears. That dream is starting to come true in Model-driven apps.

Generative Pages helps makers to turn ideas into working UI in minutes allowing you to describe the type of page you want and building it for you, including layout, controls and data.

This new feature is still evolving, but I tested and see already a huge potential for speeding up app creation, especially when working with structured Dataverse tables.

Let’s dive into what it is, how to create your first Gen page and, of course, the limitations.

What are Generative Pages?

In short, Generative Pages let you describe the page layout and purpose then, Power Apps (and Copilot) automatically generates the UI, logic and bindings. Currently only available in model‑driven apps, the GenPages works by interacting with the app agent, where you describe what you need, specify the Dataverse tables needed and can even attach images of your idea as inspiration.

How to create a Generative Page in model-driven apps?

Pre-requisites: in August 2025

This feature is only available for Model-Driven Apps (not Canvas Apps)
The Power Platform environment must be located in the US region.
It also requires Copilot features to be enabled in the environment. It's on by default

For this post, I’ll walk you through the process using a real solution I created years ago: an HR onboarding app built in a Model‑Driven App, where new hires are registered and onboarding tasks are tracked. So, the tables already exists.

Create or open a model-driven app for editing
In the app designer, select "Add a page"
Describe your page: A new tab will open and you will se a Copilot prompt like the image bellow:

Then, describe what you want to create. Example: Based on the attached image, create a page to view, edit, and add employee records from the Employees table.
...And add the tables.

Copilot instantly built a structured page, pulling data from the mentioned Dataverse tables and generating views and forms that I could immediately test and customize.

This is what I got

Then you can refine the layout, behavior and adjust the relationships in the App Agent using natural language

Considerations and limitations: August 2025

There are a few limitations to keep in mind when working with Generative Pages:

Dataverse only: You can only connect to Dataverse tables (up to 6 tables per page)
No code editing: You can't edit generated code directly. You need use the App Agent.
Manual publishing required: You need to publish each generative page separately, meaning, publishing your app won't automatically publish the pages.
Initial prompt: You must include all needed tables in the first prompt, there is no 'add later'.
Language: Only US english is supported
No collaboration: Only one maker at a time working on a gen page
Prompt history: You can just access your last 5 interactions with the App Agent.

With these limitations in mind, plan your data model and page structure in advance to avoid problems during the page generation.

Bonus: Don't skip the "Agent Thoughts!

When you generate a page or make any adjustment with the App Agent, you will find the "Agent Thoughts" just bellow the response. The Agent Thoughts give you back the interpreted request and what steps it took to build the page.

Really nice, huh?! And more, if the result doesn’t look how you imagined, this section helps you troubleshoot, improve your prompts and better understand the App agent/Copilot behavior.

Bonus 2: Unexpected behavior

While testing, the "Restore" button didn't respond, even after multiple clicks and waiting.

I also tried typing "Restore" into the prompt, thinking it might revert the page to the last published or saved version. Instead, it quickly generated a random landing page unrelated to my current project. At one point, displayed this error page.

This might just be a temporary bug, but it’s good to be aware of it.

Conclusion

Generative pages won't build everything for you, but it can help you prototype, learn and improve your app faster. Sometimes, that's exactly what you need, move faster and smarter.

[Boost]

Fernanda Ek — Tue, 10 Jun 2025 14:37:24 +0000

Fernanda Ek

Jun 9 '25

Connections in Power Platform

#powerplatform #powerautomate #powerapps #powerfuldevs

Comments 2

4 min read

Connections in Power Platform

Fernanda Ek — Mon, 09 Jun 2025 09:06:19 +0000

A while ago, I was helping a colleague with Power Automate flow when asked:

Wait, why is this flow sending emails as me instead of our shared mailbox?

Many people build flows every day without really understanding how connections work behind the scenes. So in this post, I'm going to explain everything you need to know about connections in Power Platform.

But first: What are connectors in Power Platform?

Before we jump into connections, I believe it's important to briefly explain what connectors are and how they function within the Power Platform.

One of the biggest superpowers of the Power Platform is how well it integrates with other systems. Microsoft gives us access to over 1000 connectors like SharePoint, Outlook, Teams etc and that number is growing constantly.
List of all Power Platform connectors

No matter what service you’re trying to automate or pull data from, there's probably a connector for it.

Every connector needs a connection.

That connection is like the "key" that unlocks access to that service and it’s almost always tied to a specific user account.

What is connection in Power Platform?

In Power Platform, a connection is how, for example, your flow talks to another service, like: SharePoint, Outlook, Dataverse or even external systems like Salesforce, SAP or custom API. It’s like giving Power Automate a permission to act on your behalf in those systems.

By default, it picks your own account.

That’s fine when the flow is personal. But in shared or business critical (when it supports essential operations within an organization), it can be a problem.

Connections are tied to a user or a account

When you add a connector, let's say SharePoint, Power Platform will ask for the user account. If you pick your own account, everything works great until YOU:

Leave the company,
change your password,
you go on vacation and someone else needs to fix the resource in Power Platform,
you share the resource and now other users are running actions under your identity.

Not great huh

When connections cause issues

When flows stop working: If a flow uses your personal account and your password expires or you leave the company, the flow breaks.
When flows run with the wrong identity: If you're sending emails, creating items or modifying data and it's done using your name users might get confused, specially if you are an external consultant.
When you need traceability: You can’t track ownership properly when everything’s tied to individual users.

Sharing connections

Power Automate makes it way too easy to accidentally share something that shouldn’t be shared.

Scenario

You create a flow that sends emails from Outlook using your account. You later share the flow with someone else... but forget to update the connection.

Now you’ve got someone else triggering a flow and emails are being sent under your name and mailbox.

That's awkward at best and a data privacy risk at worst.

Shared Connections ≠ Shared Responsibility

Nope.
If you’re managing shared resources in Power Platform, make sure connections are reviewed and either replaced with service accounts or managed using solutions and environment variables.

Personal productivity ≠ Business resources

If you're automating your own tasks and maybe just trying to save yourself time, that’s personal productivity. The moment your automation starts handling shared data, emailing customers, writing to shared systems or being used by others, then you're no longer in the “personal productivity” space. You're in the “business resource” space.

The difference

Personal Productivity	Business Resource
Built by and for one user	Shared across teams or part of a business process
Runs under your identity	Needs a consistent, auditable identity (like a service account)
Failure affects just you	Failure can affect teams, customers, or compliance
No risk if you leave the company	Serious risk if you're the only one who owns the connection

Using a service account means the flow will keep running, even if you’re on vacation or change teams. It also makes ownership crystal clear.

How to manage connections in Power Platform

Connections exist across the entire Power Platform, and how you manage them depends a bit on which tool you’re using. But the core idea is the same:

1. View the existing connections: Power Automate

Edit your flow
Select each action and view or change the connection
Or to manage globally: go to “Connections”

2. View the existing connections: Power Apps (Canvas)

Edit your app
Go to “Data”, you’ll see all connected data sources then you can remove, refresh, or replace each connection.

3. You also can manage these in the solution

Conclusion

Educate you team, connection management is something people don’t know they don’t know. Spread the knowledge.
...and document everything!

3 most common challenges when setting up Power Platform Governance and how to solve them

Fernanda Ek — Thu, 05 Jun 2025 18:18:31 +0000

A few weeks ago, I had a conversation with a client who asked, “Do we really need governance in Power Platform? I mean, we already have governance around Microsoft 365 and Azure. Isn’t that enough?” That question really hit because I’ve heard it so many times.

A lot of organizations I work with do understand the need for governance. The tricky part is that their focus is usually on the more traditional areas like email, Teams, identity and infrastructure not on the Power Platform. And yet, Power Platform introduces a whole new layer of tools, users and risks that aren’t covered by those existing policies.

Implementing Power Platform governance is often a complex, layered process and even organizations with strong foundations in Microsoft 365 and Azure can find themselves overwhelmed by the new concepts and responsibilities that Power Platform brings.

In todays post I will try to break down the 3 most common challenges I’ve encountered when working with Power Platform governance and I’ll provide my ways to overcome them.

Challenge 1: IT Admins are unfamiliar with Power Platform concepts

Many IT administrators are comfortable with Microsoft 365 and Azure, but the Power Platform introduces new paradigms: environments, Power Platform DLP (Data Loss Prevention) policies, custom connectors, solutions, makers, and more. It's not uncommon to see IT professionals struggle with the admin interfaces or how it brings new things to the table. Some admins find it tricky at first.

Why this happens?

Power Platform lives in that space between IT and business users. The platform gives business users (makers) powerful tools, which introduces risks if not understood or managed properly. If IT doesn't have a clear understanding, they often can't provide appropriate guardrails.

What you/your org can do?

Start with Education: Encourage your IT team to engage with the Power Platform Community, blogs and Microsoft's documentation to stay updated on best practices and when possible.
Use the Power Platform Admin Center: Familiarize yourself with the Admin Center, it’s your control tower for managing environments, capacity, analytics, and policies.

Join the Community: Engage with the Power Platform Community, blogs and Microsoft's documentation to stay updated on best practices.

Challenge 2: No one knows what has been built, by whom, or why

In an open, ungoverned environment, apps and flows get created organically. Over time, people in different departments build apps and flows. But without governance, nobody tracks who built what, where it’s running or even if it’s still needed.

Why this happens?

Power Platform is easy to adopt, which is its strength and weakness. Without governance from the start, users create apps to solve local problems without oversight or documentation.

What you/your org can do?

Implement the Center of Excellence (CoE) Starter Kit (read more here) this solution helps you track app and flow inventory, maker activity and usage trends. It includes:

App/Flow inventory
Environment insights
Orphaned resources reporting
Nurture communications to support makers

…and maybe, implement a 'request process', I mean ask users to submit a short form describing the purpose, owner, and data used before publishing solutions to production.

Challenge 3: Responsibilities for managing the Platform have not been defined

In many organizations, it's unclear who is responsible for different aspects of Power Platform governance. Who’s in charge of what? Who handles support? Who approves new environments? If you don’t define this early, things can slip through the cracks.

Why this happens?

Power Platform is used by both IT and business teams. That’s great for collaboration, but it also causes confusion over who’s responsible for what.

What you/your org can do?

Define roles and responsibilities using a RACI (Responsible, Accountable, Consulted, Informed) Matrix model.

Here’s what those roles mean:
Responsible: The person (or team) who actually do the work.
Accountable: The one who makes sure the work gets done and signs off on decisions.
Consulted: People who should be asked for input or advice before things move forward.
Informed: People who just need to be kept in the loop.

For example:

Designate a Platform Owner. This person or team will be responsible for maintaining platform strategy, alignment and overall governance. They bridge the gap between business needs and IT control.

In big companies, let each department have their own mini-admins while still following central rules.

Conclusion

Governance isn’t about restricting users, it’s about empowering them with the right support and boundaries to innovate safely and sustainably.

While it’s tempting to delay governance until you "have more apps" or "understand more," starting small with visibility and education will put you miles ahead.

BONUS: If you’re just getting started, begin with visibility like the CoE Starter Kit and define a few simple rules. You don’t need a perfect setup from day one just a direction and some small wins.

Setup document templates in Microsoft Teams using Power Automate

Fernanda Ek — Tue, 01 Apr 2025 15:36:38 +0000

Have you ever wondered: “Can we, and if so, how do we make our Word and Excel templates available under the 'Files' tab and 'New' button inside all Teams channels?”?

The answer is YES and no, you don’t need to go into every single channel and do it manually 😅 ~~Imagine having to distribute templates to hundreds of Teams channels across your organization… Yeah, no thanks.~~
That’s where Power Automate comes in and saves the day.

But before... let’s talk a bit about Microsoft Teams

Every time a team is created in Microsoft Teams, a corresponding SharePoint site is also created in the background. The Files tab in each channel is simply a document library in that SharePoint site. So when you click “New” in Teams to create a new Word or Excel file, it’s actually pulling from a folder in SharePoint and that’s exactly where your custom templates need to live.

Knowing this, we can use Power Automate to target the SharePoint library directly and automate the process of uploading templates to the correct location.

Prerequisites

Be a member: The service account running the flow must have access to each Teams channel
SharePoint admin permissions: since we’ll be creating a custom content type and managing it from the SharePoint Admin Center

Step 1:Content type

Start by creating the content type from the SharePoint Admin Center. In the SharePoint Admin Center, go to
Content services > Content type gallery > Create content type.

Fill in the following fields:

Name: Something meaningful like Contoso Internal Template

Description: Optional, but great for keeping track of what the template is for

Parent content type: Select “Document Content Types”

Content type: Document. Create

Once created:

Open your Content type and select Settings > Advanced settings
Select “Upload a new template” and upload the template. Save.

Now that your content type linked to a specific document template, it’s time to publish it so it becomes available across all SharePoint sites including the ones behind your Teams channels.
This process can take a few minutes to propagate, especially in larger tenants.

Once published, the content type will be available to add in any SharePoint document library.
Checking in a random site collection
Before publishing

After publishing

Step 2: Enable Content type

Before we can add our custom content type to each Teams library, we first need to enable content types in those libraries because by default, SharePoint document libraries (including the ones behind Teams) don’t allow multiple content types.

In our case, we created a manually triggered Power Automate flow that retrieves all Teams and loops through them.

Inside our loop, we send a HTTP request to SharePoint to enable content types in the Documents library (or the correct library path).
Method: POST
URI:

/_api/web/lists/GetByTitle('Your library name')

Headers:

{
  "Accept": "application/json;odata=verbose",
  "Content-Type": "application/json;odata=verbose"
}

Body:

{
  "__metadata": { "type": "SP.List" },
  "ContentTypesEnabled": true
}

This will modify the document library to allow content types, which is required before you can attach the custom content type we published earlier.

Step 3: Add the custom content type to the site

Now we’ll add the custom content type to each site using another a couple of API request and make sure that our template appear in Teams!

Add a new 'Send an HTTP request to SharePoint'-action inside our loop and configure as bellow.

This will add a copy of our published content type from the content type hub to a target site.

Method: POST
URI:

/_api/v2.0/sites/TEAMNAME/ContentTypes/addCopyFromContentTypeHub

Headers:

{
  "Content-Type": "application/json;odata=verbose"
}

Body:

{
"contentTypeId": "0x010100 YOUR CTID"
}

Get the CTID: By going back to the Content Type > Gallery in the SharePoint Admin Center > Clicking on your content type > Copying the Content Type ID from the details page

Step 4: Add the custom content type to each library

Now that content types are enabled in the libraries and available in the site, the next step is to add our custom content type to each SharePoint document library connected to a Teams channel.

We will use another 'Send an HTTP request to SharePoint'-action inside our loop, as bellow.

Method: POST
URI:

/_api/web/lists/GetByTitle('Documents')/ContentTypes/AddAvailableContentType

Headers:

{
  "Content-Type": "application/json;odata=verbose"
}

Body:

{
"contentTypeId": "0x010100 YOUR CTID"
}

📌 Replace "0x010100 YOUR CTID" with the actual Content Type ID from the Content type gallery.

Run the flow

After the flow runs successfully across your selected Teams channels, you can validate the outcome in two places:
SharePoint library

Teams

Voilà

And there you have it, your custom document templates are now available under the New button in the Files tab of every Teams channel in your organization.

Using Power Automate to migrate SharePoint documents from one tenant to another while preserving System Columns

Fernanda Ek — Tue, 01 Apr 2025 11:37:37 +0000

The background

After my previous post Updating SharePoint Items Without Modifying System Columns, I got a really good question on LinkedIn. First of all, I’d like to take the opportunity to thank everyone who reached out and connected, it's been great seeing the interest and feedback!

The question was whether the same kind of logic could be applied to documents instead of list items. And more than that, "could it work across tenants?".
He meant: create new documents in another tenant based on documents in a source tenant, and keep system columns like "Created", "Created by", "Modified", and "Modified by" intact.

That got me thinking.

Up until now, I’ve mostly done tenant-to-tenant migrations using tools like ShareGate, which make the process much easier. But I was curious to see what could be done directly in Power Automate. So, I decided to try and build a flow that moves documents from one SharePoint tenant to another without relying on third party tools.

Note: We’re talking about a few documents here, not massive libraries or thousands of files.

The challenge

Copying files between sites in the same tenant is straightforward in Power Automate. But what if you try to move something to another tenant, would the usual "Create file" or "Copy file" actions work?

The workaround

What I discovered is that it’s possible to set up a flow that writes to a site in another tenant, you just have to add a new connection to the SharePoint connector using credentials from the destination tenant. Magic huh

Here's how we make it work

Build your flow as usual, up until the point where you need to create the file in the target library in the destination tenant.

Use your source tenant credentials for the "Get file properties", "Get file content", etc. actions.

Then:

Add the "Create file" action
Classic design: Click the three dots (…) in the top right of the action and select "Add new connection".

Modern design: Select the action, and in the panel that opens on the left, down to the bottom, select "Change connection", then click "Add new connection".

Once connected, you’ll be able to select the site and folder path from the destination tenant just like you would within your own.

Now to the point, while it’s totally possible to copy documents across tenants using Power Automate, keeping system columns like "Created" and "Modified" is where things get complicated.
If you follow the steps in this article Updating SharePoint Items Without Modifying System Columns you will be able to preserve the original timestamps (Created/Modified dates). For author and editor (Created by / Modified by), those accounts must exist in the destination tenant, ff they don’t, you’ll need to assign another user account, I would recommend a service account.

Conclusion

I’m still experimenting but can already confirm that document migration across tenants is possible using Power Automate. Even better, I was able to create new documents in a destination library based on a source library in another tenant, and keep the information in the system columns like Created, Modified, Created by, and Modified by (as long as the users exist).

Updating SharePoint items without modifying System columns

Fernanda Ek — Sat, 26 Oct 2024 08:55:45 +0000

When working with SharePoint, there are scenarios where you need to update a library/list item’s information but want to keep the system fields, like Modified and Modified By, intact. In this blog post, I’ll walk you through how to update custom columns in a SharePoint list while preserving these system columns.

Why Is This Useful?

Imagine you have a live application and need to add new columns to an existing list or modify data without affecting the historical metadata, such as who modified or last modified the item. We want ensure that only the new information is updated and the record’s creation and modification details remain untouched.

Scenario

Let’s take a SharePoint list named “Desks Reservations” where we store Desk Name, Description, etc. We now need to add an 'Reserved By email'-column and populate it with existing records without changing the original Created By, Created, Modified By and Modified fields.

1. Using PnP PowerShell

We could use a PnP PowerShell script to modify specific fields while preserving the metadata related to who modified or created the item. The script would include a section that might look something like this:

# Update the fields
Set-PnPListItem -List $ListName -Identity $ItemId -Values @{
    "Title" = "Test Title"; 
    "Category"="Test Category"
}

# Preserving system fields explicitly
Set-PnPListItem -List $ListName -Identity $ItemId -Values @{
    "Created" = $page.FieldValues["Created"];
    "Modified"= $page.FieldValues["Modified"];
    "Author" = $page.FieldValues["Author"].Email;
    "Editor" = $page.FieldValues["Editor"].Email;
}

2. Using Power Automate

Another alternative (and the focus of this article) for performing this type of operation is to use Power Automate.
Power Automate provides actions like 'Update Item' or 'Send an HTTP request to SharePoint' that can be used to update fields in a SharePoint list. When updating custom fields, you have to take additional steps to preserve the system columns by capturing the original values and then restoring them, similar to PowerShell.

So, how it works?
By default, whenever you update a SharePoint item, the system will change the 'Modified' and 'Modified By' fields to reflect the current user and the time the update was made. What we will do is send an HTTP request to submit the original values along with our updates, similar to the PowerShell approach.

Set up

1. Create an Instant Cloud Flow: make.powerautomate

2. Retrieve SharePoint items:

3. Add Compose Actions: Use two Compose actions to store the 'Created By'-email and 'Modified By'-email for each item. This will allow us to re-apply these values after we update the custom field.

4. Create a JSON structure: Include the custom fields you wish to update (like 'Reserved By email') and also pass the system fields that we want to preserve.

Date formating expression:

formatDateTime(items('Apply_to_each')?['Created'], 'yyyy-MM-dd hh:mm:ss')

Note: Author is the internal name for the Created by-field and Editor is the internal name for the 'Modified by'-field.

5. Send the update request: Use the Send an HTTP request to SharePoint action to post this data to your list. The method will be POST and the URI will point to the specific list and item:

_api/web/lists/getbytitle('Desk Reservations')/items(ID)/ValidateUpdateListItem

The bNewDocumentUpdate property is used in the HTTP request to indicate whether the update should be treated as a new or as a regular item update. When it's set to false, it prevents the system fields from being automatically updated with new metadata.

PowerShell vs. Power Automate

PowerShell	Power Automate
Ideal for large-scale or batch processing of SharePoint list items.	Better for individual item updates or smaller-scale operations.
Requires scripting knowledge.	Easier to manage.

My thoughts

The choice between PowerShell and Power Automate depends on your specific needs. If you're performing large-scale operations, PowerShell might be the best option. On the other hand, if you’re looking for a more accessible, low-code solution with an intuitive interface, Power Automate is ideal.

Testing

Before:

Behind the scenes

After Voilà

Conclusion

Ultimately, the right choice depends on the complexity of your task and your familiarity with scripting. Regardless of the tool you choose, you can efficiently manage SharePoint data while preserving system metadata.

Power Platform strategy with CoE

Fernanda Ek — Sun, 13 Oct 2024 15:15:26 +0000

SPOILER ALERT: This is going to be a looong article 😅 But my hope is that it will answer many questions about this topic.

More and more companies are turning to automation to simplify their processes, which is, obviously, great. However, despite the growing popularity of Microsoft Power Platform (which is also great), some companies have yet to establish a clear strategy or a way to track what’s happening in their environments.

This lack of governance can lead to a wild west of uncontrolled environments, often starting with the default environment, where there’s little oversight into who is creating what, how apps and flows are being shared or whether sensitive data is at risk.

The default environment, if unmanaged, can quickly become chaotic. This exposes the organization to significant risks such as:

Security vulnerabilities: apps using unauthorized connectors.
Data governance issues: apps and flows are shared without proper control.
Difficulty scaling: users adopt the platform without a clear understanding of best practices.

Now to the reason I’m writing this blog post

I'm often asked to perform a Power Platform analysis, reviewing Power Automate flows and Power Apps applications and to provide recommendations.

From what I’ve seen businesses find themselves in situation where they’ve enabled citizen development but lack a centralized way to track and manage the applications and automations that have been created. Without a proper Center of Excellence (CoE) in place, companies face the risk of duplicated efforts, apps going unmonitored or, worse, critical data breaches

This blog post is here to address those challenges and to show how establishing a Power Platform CoE (specifically using the CoE Starter Kit) can bring order, governance and innovation, ensuring your automation initiatives stay secure, compliant and aligned with your business goals.

Let’s dive in!

Introduction to Power Platform Center of Excellence (CoE)

The Power Platform Center of Excellence (CoE) is designed to help organizations adopt, govern and scale their use of Microsoft Power Platform. It brings together a set of tools and components aimed at providing administrative oversight, encouraging best practices and fostering innovation. The CoE plays a crucial role in managing environments, supporting makers, and ensuring that apps, flows, and connectors are used efficiently and securely.

What is the CoE Starter Kit?

The CoE Starter Kit is a collection of Power Apps, Power Automate flows, Power BI reports and tools that help organizations implement a CoE. It provides a framework for managing governance, nurturing makers and automating workflows. Some key components include:

1. Core components: Tools that help admins manage resources like apps, flows and environments across their tenant. This includes inventory management, Power BI dashboards and apps like the DLP Impact Analysis and Set New App Owner.

2. Governance components: These help enforce governance policies through features like app archival and compliance monitoring.

3. Nurture components: To support makers within the organization. The CoE includes Welcome email Flow and components designed to onboard new makers and share best practices.

It’s important to clarify that a CoE is not just about tools, but also about the people involved in managing and supporting the platform.

A CoE team may include roles like admins, solution architects, citizen developers and governance specialists. Having the right team in place is critical for maintaining control over Power Platform solutions, ensuring that governance policies are followed and supporting users across the organization

Benefits of implementing the CoE Starter Kit

1. Governance and process standardization: The CoE Starter Kit helps enforce governance across Power Platform environments, ensuring that apps and flows adhere to data security and organizational guidelines. It also simplify processes like environment requests and user activity tracking.

2. Lifecycle Management: The CoE Starter Kit helps track component creation and usage as well as identify inactive apps and flows. It automates the environment cleanup process with tools like App Archive and Cleanup.

3. Data Loss Prevention (DLP): The CoE includes a DLP Impact Analysis that provides visibility into how new policies might affect existing apps and connectors.

Microsoft CoE vs. Power Platform CoE

If your organization already has a Microsoft Center of Excellence (CoE), you might wonder if this covers your Power Platform needs. While a Microsoft CoE can support broader IT governance, a Power Platform CoE ensures that Power Platform specific activities, such as Data Loss Prevention (DLP) and app ownership, are appropriately managed.

Differences in Data Loss Prevention (DLP) between Microsoft and Power Platform governance

DLP policies exist in both Microsoft 365 and Power Platform governance, but they serve different purposes.

Microsoft 365 DLP: This is generally focused on managing sensitive information across Microsoft 365 services like SharePoint. The policies are broader and designed to protect critical business data from being shared externally or stored improperly.
Power Platform DLP: It focuses specifically on how connectors interact with data across apps and flows by preventing unauthorized connectors from accessing sensitive data.

Recommended for medium to large business

Smaller companies may not immediately require the full suite of governance tools offered by the CoE Starter Kit, making it better suited for medium to large enterprises. These organizations often have multiple departments with varying levels of Power Platform adoption, making governance and user support essential.

How to get started

Prerequisites to set up the CoE Starter Kit:

A Power Apps Per User license and Power Automate Per User or Per Flow license.
Admin access to the tenant with the Power Platform Admin or Global Tenant Admin role.
Install and configure the CoE Starter Kit

Conclusion

With Copilot, it’s easier than ever to create solutions, but that also means it’s easier to miss important governance steps. Without a CoE in place, apps could be deployed with insufficient security measures, leading to potential data leaks or unauthorized access. In short, the CoE isn’t just about managing what’s already been created, it’s about preparing for future success in a fast changing digital world.

Using Parent and Child Flows for better workflow management

Fernanda Ek — Mon, 15 Jul 2024 06:03:18 +0000

If you've been using Power Automate, you might have come across the term "parent flows" or "child flows." These concepts are super useful for organizing and managing your automation processes efficiently. In this blog post, I'll break down what parent flows and child flows are, why you should use them, and how to get started with them. Let's dive in!

What are Parent Flows and Child Flows?

Parent flows

Parent flows refer to the primary flow that calls another flow within Power Automate. Think of it as a larger process that includes smaller, specific tasks handled by other flows. This helps keep your main flow clean and focused while separating complex tasks into manageable pieces.

Child flows

Child flows are a type of flow where a primary flow (the "parent") initiates another flow (the "child") to handle a specific task. The parent flow can then continue its process or wait for the child flow to complete and return results. This approach is excellent for reusing common tasks across multiple flows.

Why use Parent and Child flows?

Break down complex processes into simpler, reusable components.
Easier to update and manage smaller, focused flows.
Use the same child flow in multiple parent flows, saving time and effort.
Efficiently manage and scale your automation processes.

Setting up Parent and Child Flows

Note: Both parent and child flows must be created within a solution.

Solutions are containers for grouping related flows, which simplifies management and deployment.

Step 1: Create your Child flow

Go to Power Automate: Open Power Automate and create a new flow.
Define Trigger and Actions: Set the trigger for your child flow.

Add the necessary actions to perform the task.
Add Response Action: If your child flow needs to return data to the parent flow, include a "Response" action at the end.

Step 2: Create Your Parent Flow

New Flow in Power Automate: Create another new flow that will act as your parent flow.
Add Actions: Define the trigger and initial actions for the parent flow.

Invoke Child Flow: Use the "Run a Child Flow" action to call your child flow. Pass any required inputs to the child flow.

Step 3: Handle Child Flow Responses

Configure Response Handling: If your child flow returns data, set up the parent flow to handle this data. This might involve adding conditional logic or further actions based on the child flow's output.
Test Your Flows: Run your parent flow and ensure that it correctly calls and interacts with the child flow.

Common Errors and Troubleshooting

When working with parent and child flows, you may encounter several common errors. Here's how to recognize and troubleshoot them:

Error: Multiple response actions

'The schema definition for action with status code '200' is invalid. The schema definitions for actions with the same status code is missing.'

Issue: Having more than one response action in your child flow with different schemas.
Solution: Ensure that all PowerApps response actions in the child flow have the same schema or consolidate them into a single response action.

Error: Inactive Child Flow

Issue: The child flow is inactive or has been deleted.
Solution: Verify that the child flow is active and exists. Reactivate or recreate the child flow if necessary.

Error: Incorrect "Connections used"

Issue: The "Run only users" > "Connections used" is incorrect (Provided by the user run-only user), preventing the parent flow from executing the child flow.

Solution: Check the "Run only users" settings in the child flow and update the "Connections used".

Best Practices for Parent and Child Flows

Clear Naming Conventions: Use descriptive names for your flows to easily identify their purpose.
Documentation: Document the functionality of each flow, especially if it's used in multiple parent flows.
Error Handling: Implement error handling in both parent and child flows to manage and log issues effectively.
Regular Maintenance: Periodically review and update your flows to incorporate new features and improvements.

Conclusion

Parent and child flows in Power Automate can significantly improve the efficiency and manageability of your automation processes. By breaking down complex tasks into smaller, reusable components, you can create more modular, maintainable, and scalable flows. Try them out and see how they can upgrade your workflows!

Power Platform Hack: Turning a Managed solution into Unmanaged

Fernanda Ek — Tue, 25 Jun 2024 16:36:41 +0000

Hey folks! 👋 I’ve got quite a story to share about a little sweaty moment I had with Power Platform. If you’ve ever had a situation where you needed to convert a managed solution into an unmanaged one, keep reading… I’ve got a trick for you.

How it all started: Importing

So there I was, trying to import a solution back into my Power Platform environment. I got this error:

"The import solution must have a higher version than the existing solution it is upgrading."

Honestly, I wasn’t sure how to fix it 😵‍💫

The Discovery

Not one to give up easily, I decided to dig into the solution file itself. I unzipped the solution and opened the solution.xml file. This file contains all the details of your solution. Here’s a peek at the code:

<ImportExportXml version="9.2.24052.196" SolutionPackageVersion="9.2" languagecode="1033" generatedBy="CrmLive" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <SolutionManifest>
    <UniqueName>QMS</UniqueName>
    <LocalizedNames>
      <LocalizedName description="QMS" languagecode="1033" />
    </LocalizedNames>
    <Descriptions />
    <Version>1.0.0.4</Version>
    <Managed>0</Managed>
    <Publisher>
      <UniqueName>xxxxxxxxx</UniqueName>
      <LocalizedNames>
        <LocalizedName description="xxxxx" languagecode="1033" />
      </LocalizedNames>
      <Descriptions />
      <!-- Other tags omitted for brevity -->
    </Publisher>
    <RootComponents>
      <!-- Components list -->
    </RootComponents>
    <MissingDependencies />
  </SolutionManifest>
</ImportExportXml>

I noticed the <Version> tag and thought, “What if I just bump up the version number?” So, I changed <Version>1.0.0.4</Version> to something higher, like <Version>1.0.0.7</Version>, saved the file, zipped it back up, and tried importing it again. Success! 🎉

The “Eureka” moment with `<Managed>`

While I was poking around, another tag caught my eye: <Managed>. It was set to 0, which means it was an unmanaged solution.

Note: In the context of many programming languages, 0 and 1 are used as Boolean values to represent false and true, respectively.

Curious, I wondered what would happen if it was a managed solution, if it was set to 1🤔 Then I decided to test it out with a managed solution… I changed it to 0.

• 1: This means the solution is managed. Managed solutions are typically used in production environments where you don’t want users to modify the solution directly. The 1 here is like saying “Yes, this is managed.”
• 0: This changes the solution to unmanaged. Unmanaged solutions are often used in development environments because they allow for direct modifications. The 0 here is like saying “No, this is not managed.”

So, by changing the tag from 1 to 0, you’re effectively telling Power Platform that the solution should no longer be treated as a managed solution, allowing you to edit and customize it freely.

So, I did just that:

<Managed>0</Managed>

I saved the file again, zipped it up, and imported it back into my environment. And guess what? The solution was now imported as an unmanaged solution! 🎉

Here’s how to do it

Unzip and Edit:
- Unzip the exported file and open solution.xml.
- Change the <Managed> tag from 1 to 0.

If you’re facing a version issue, update the <Version> tag to a higher number.

I find it easier opening it directly in Visual Studio Code, you can of course open with notepad as well.

Zip and Import:
- Zip up the files and import the solution back into your environment.
Voilà! You now have an unmanaged solution.

When to use this trick

Managed solutions are great for deploying stable versions to production environments but if you ever need to modify something or if you’ve somehow lost your unmanaged version and need to make changes, this little trick can save you tons of time.

Conclusion

While this trick works, it’s more of a workaround than an official method. Use it wisely and always keep backups of your solutions. Also, keep in mind that this might not be suitable for all scenarios, especially in production environments where stability is key.

I hope this helps you out as much as it did for me 🚀