DEV Community: Brandon Wozniewicz

What Power Apps Components Can Learn from Your Favorite Café

Brandon Wozniewicz — Thu, 24 Jul 2025 15:00:00 +0000

A good component is like your favorite coffee shop.

You place your order.

The barista prepares your drink.

When it's ready, they call your name and hand it over — just the way you expected.

And the best part? If you order the same drink tomorrow, it'll taste the same.

In this article, you'll learn:

What a component is—in plain terms
How inputs, outputs, and events relate to our coffee shop
Three simple rules for building scalable components in power apps
A real-world example of password matching

What is a Component?

A component is a building block — one small part of something bigger.

A LEGO brick is a component. Stack enough together, and you get a spaceship.

Or take your car: it's made up of smaller components, such as the engine, wheels, and doors.

Each part has a specific purpose, and when assembled, they form something useful.

In programming, it's no different. A component is a reusable piece of code. Alone, it might render a button or a label. Together with other elements, it helps build entire applications.

How inputs, outputs, and events relate to our coffee shop

Just like LEGO bricks or car parts, components often take inputs and produce outputs.

Inputs flow into the component—instructions from the outside
Outputs from out of the component— data or signals sent back to whoever's listening

This relationship is often referred to as a parent-child arrangement.

The parent is the screen or component that "hosts" another component inside of it.
The child is the reusable component that is placed inside the parent— like a coffee shop inside a larger shopping center.

The parent gives the child its settings (inputs).

The child does its job and lets the parent know when something happens in the form of outputs and events.

The Coffee Shop (Child Component) in Plain Terms

Exists within a parent— the shopping center
Inputs = Your order (e.g., "Oat milk latte, no foam)
Logic = The barista behind the counter
Event = "Order for Sam!" — a signal that something has happened.
Output = Your drink

That's the model: a clean component takes instructions, performs its job, and notifies you when it's done.

But what does that actually look like in Power Apps?

Let’s walk through three simple rules that will help you design components that are easy to reuse, easy to test, and hard to break.

Three simple rules for building scalable components in Power Apps

Rule #1: Take the Order and Follow the Recipe

A well-designed component is like a well-run coffee franchise— it should function the same way, regardless of its location.

It doesn't matter what's happening at the restaurant next door.

It doesn't matter if it's the morning rush or a quiet afternoon.

And it definitely doesn't matter which location you visit — you expect your usual drink to come out… well, as usual.

Good components don't reach into the parent screen to grab what they need.

They don't rely on global variables.

And they don't make assumptions.

If a component needs information — like a title, color, or mode — that's handled through explicit inputs.

If the parent needs information back, that is handled through explicit outputs.

Rule #2: Make the Same Order the Same Way Every Time

When you order a #5, you always expect the same drink.

It doesn't matter if there's a new barista behind the counter or they've upgraded the espresso machine — your oat milk latte should taste the same.

Your components should behave similarly.

In Power Apps, if a component receives an input like Title = "Are you sure?", that same title should appear the same way every time — without surprises.

It shouldn't sometimes include an emoji.

Or occasionally add extra punctuation.

While the parent provides the settings (inputs) to the component, how the component uses them to produce the output is up to the component.

These are called implementation details. And the parent component shouldn't have to care.

You ordered a drink with a tablespoon of sugar.

You don't care if they used a tablespoon or three teaspoons — as long as the drink tastes right.

That's precisely what makes a component testable, reusable, and predictable.

Rule #3: Announce When It's Ready

Imagine the barista finishes your drink… and then leaves it on the counter.

No name on the drink. No name called. No order number announced. No signal at all.

You sit there wondering what's taking so long — while your drink is slowly getting cold.

That's what happens when a component forgets to raise an event.

In Power Apps, when something meaningful happens — such as a button click or a value selection — the component should notify its parent.

To do this, the child component raises an event — such as OnSubmit, OnItemSelected, or OnChange — to notify the parent that something important has just occurred.

A button was clicked.
A choice was made.
A step was completed.

The component raised its hand and said, "Hey — something's ready."

The parent can then listen and react to these events.

A Real-World Example: Password Matching

It's time to apply these concepts with a real world example. Let's say you're building a form with two fields:

Password
Verify Password

Here is a suboptimal way to build it:

You have two separate input components.
Each has a static label: "Password" and "Verify Password".
The second component checks a global variable to get the value of the first input.
It uses that global value to decide whether to show a message like: "Passwords do not match"

The problem?

This component isn't isolated — it's reaching outside itself to gather what it needs. It only works because of the specific screen it's on. Move it somewhere else, and it breaks.

A Better Approach: Reusable and Self-Contained

Let's improve this by building a single, reusable input component that works for both password fields.

Here is how it works. This component:

Accepts a LabelText input, like "Password" or "Verify Password," and displays it above the text input.
Accepts a HintText input, like "Passwords must match" or "Must include 1 special character", and displays it below the field.
Exposes a Value output—the current text input value.
Raises an OnChange event whenever the user types something new.

Now, you can drop this component in any form: One for the password and one for the confirmation field.

And, on the parent screen, you can handle the matching logic:

Listen for OnChange from either input.
Compare their Value outputs.
Update the HintText of the second input accordingly.

Summary

A well-built component is like a well-run coffee shop — or, better yet, a coffee shop franchise.

It waits for your order (input), prepares your drink behind the counter (logic), calls your name when it's ready (event), and hands you exactly what you expected (output).

It doesn't guess, and it doesn't fall apart if you open a new location.

By focusing on clear inputs, consistent outputs, and intentional events, you'll create components that are easy to reuse, easy to reason about, and ready to scale.

If you want a practical look at canvas apps components, check out this article.

Found this helpful? I work at the intersection of low-code and pro-code development, focusing on building performant apps and helping you reclaim your time through thoughtful automation. Explore more right here at scriptedbytes.com

How to Assign Dataverse Security Roles at Scale

Brandon Wozniewicz — Thu, 26 Jun 2025 15:00:00 +0000

Assigning Dataverse security roles manually works–until it doesn't.

Whether you are onboarding 50 new hires or rolling out access to a new app, managing roles by hand can be tedious and error-prone.

In this article you will learn three scalable ways to assign security roles across multiple users or teams, with low-code and pro-code options.

Canvas Apps Relate/Unrelate Functions
Power Automate and the Relate Rows Action
C# Console App using the Dataverse SDK

Aside: Teams

Teams are the simplest way to assign roles to multiple users.

Dataverse admins and team owners can add users to one or more teams. Rather than assigning roles to individual users, the security role is assigned to the team.

However, there are caveats—record ownership and team management can introduce their own complexity. In environments with many teams, updating security roles can become just as tedious as assigning them individually.

This article focuses on programmatic individual assignments, but keep in mind that all three methods described below can be adapted to work with teams as well.

Canvas Apps Relate / Unrelate Functions

Canvas app developers can use Power FX to assign security roles across users or teams. Minimal code is required, and the result can serve as a lightweight security role management portal.

While not ideal for massive batches, this approach is suitable for assigning roles to a few hundred users.

ForAll(
    colSelectedUsers As User,
    Relate(
        User.'Security Roles (systemuserroles_association)',
        cbx_securityRoles.Selected
    )
)

Here:

colSelectedUsers is a collection of users.
cbx_securityRoles is a Combobox control holding the security role to assign.

The Relate function connects each user with the selected security role. The first parameter is the many-to-many relationship (systemuserroles_association) between systemuser and role.

To find relationship names, open the User table > Relationships. Then, look for many-to-many connections to the role table.

Power Automate with the Relate Rows in Dataverse Action

The Relate Rows in Dataverse action allows you to assign roles dynamically in cloud flows.

How it works:

Trigger a flow (e.g., manually or via Dataverse trigger).
Fetch a list of users based on a condition.
Loop through each user with Apply to Each.
Assign a static or dynamic security role.

C# Console App: Using the Dataverse SDK

This method offers maximum control and supports complex, high-scale role assignments—but it requires pro-code skills.

Example:
This console app:

Connects to the environment via client credentials.
Retrieves all users with the title "Salesperson"
Builds a batch of associate requests.
Executes the batch transactionally–if one fails, all fail.

using Microsoft.PowerPlatform.Dataverse.Client;
using Microsoft.Xrm.Sdk;
using Microsoft.Xrm.Sdk.Messages;
using Microsoft.Xrm.Sdk.Query;

class Program
{
    static void Main(string[] args)
    {
        string dataverseUrl = "https://your-org.crm.dynamics.com";
        string clientId     = "client-id-here";
        string clientSecret = "client-secret-here";
        string tenantId     = "tenant-id-here";

        string connectionString = $@"
            AuthType=ClientSecret;
            Url={dataverseUrl};
            ClientId={clientId};
            ClientSecret={clientSecret};
            TenantId={tenantId};
        ";
        // Connect to our environment
        using var serviceClient = new ServiceClient(connectionString);

        if (!serviceClient.IsReady)
        {
            Console.WriteLine("Failed to connect.");
            return;
        }

        // Fetch a list of users that we intend to associate a role with
        var query = new QueryExpression("systemuser")
        {
            ColumnSet = new ColumnSet("systemuserid"),
            Criteria = new FilterExpression
            {
                Conditions =
                {
                     new ConditionExpression(
                        "title",
                        ConditionOperator.Equal,
                        "Salesperson"
                     ),
                }
            }
        };

        var users = serviceClient.RetrieveMultiple(query);

        // Role to assign (pretend guid for demo purposes)
        var securityRoleId = new Guid(
            "00000000-0000-0000-0000-000000000ABC"
        );

        // Prepare our transaction
        var transaction = new ExecuteTransactionRequest
        {
            ReturnResponses = true,
            Requests = new OrganizationRequestCollection()
        };

        // For each user we fetched above, we add an associate request 
        // to the transaction
        foreach (var user in users.Entities)
        {
            var userId = (Guid)user["systemuserid"];

            var relationship = new Relationship(
                "systemuserroles_association"
            );

            var relatedReferences = new EntityReferenceCollection
            {
                new EntityReference(
                    "role",
                    securityRoleId
                )
            };
            // build the associate request
            var request = new AssociateRequest
            {
                Target = new EntityReference(
                    "systemuser",
                    userId
                ),
                RelatedEntities = relatedReferences,
                Relationship = relationship
            };
            // add the request to the transaction
            transaction.Requests.Add(request);
        }

        // Finally, execute the batch as a transaction
        serviceClient.Execute(transaction);
    }
}

You can even utilize this logic within a Custom API, allowing Power Automate or Canvas Apps to call it, blending low-code and pro-code capabilities.

Final Thoughts

If your teams are already well-structured and manageable in number, teams remain the easiest way to assign roles at scale.

However, when teams aren't feasible–or when assigning directly to users is required–each method discussed offers a viable alternative:

Use Canvas Apps for lightweight, user-facing management portals
Use Power Automate when complexity is low and there is a need to trigger it in a variety of ways.
Use C# and the Dataverse SDK for full control and batch efficiency.

Ready to automate your role assignments? Start small—build a simple Power App or Flow—and scale your approach from there. Check out more tips and tricks at ScriptedBytes.com

Originally published on Scripted Bytes, where I write about scalable low-code development and app architecture.

How to Reduce Technical Debt in the Power Platform

Brandon Wozniewicz — Sat, 14 Jun 2025 11:30:11 +0000

Technical debt refers to the future cost—measured in terms of time, money, effort, or opportunity—of choosing expedient solutions today instead of more deliberate and scalable ones. And it's not just a pro-code concept.

It might be easier to understand if we compare it to financial debt.
Howard G. Cunningham—the creator of the first wiki—described technical debt this way:

Shipping first-time code is like going into debt. A little debt speeds
development so long as it is paid back promptly with a rewrite. Objects
make the cost of this transaction tolerable. The danger occurs when the
debt is not repaid. Every minute spent on not-quite-right code counts as
interest on that debt. Entire engineering organizations can be brought to
a stand-still under the debt load of an unconsolidated implementation,
object-oriented or otherwise.

In this article, you'll learn why technical debt is just as much a concern in low-code projects as in traditional development—and why, in some ways, it can be even more prominent. We'll walk through eight common contributors to technical debt in Power Platform projects that, if left unchecked, can lead to future headaches.

Why Technical Debt Is Also a Low-Code Problem
Hard-Coded or Static Values in Your Code
Duplicated Code
Poor Naming of Controls and Variables
Overloaded Screens and Apps
No Version Notes
Invisible Logic
Denormalized Data Models
Leading with Layout Before Logic
Wrapping Up

Why Technical Debt Is Also a Low-Code Problem

Technical debt builds when short-term decisions ignore long-term consequences. While it exists in any development, low-code platforms increase the risk for a simple reason: they remove much of the traditional friction that forces teams to slow down.

With fewer barriers to entry, it's easier for citizen developers — and even professional developers new to the platform — to start building without considering maintainability, scalability, and security.

Low-code platforms enable speed — but if you aren't intentional, the speed can create an environment that fosters the growth of technical debt.

Examples of Technical Debt in a Low-Code Project

Hard-Coded or Static Values in Your Code

We've all seen code like this:

Office365Outlook.SendEmailV2(
  gblAuthenticatedUser.Email, 
  "Sign-Up Request Received!", 
  "A team member will reach out shortly with more information."
)

At first glance, this appears to be fine. But what happens if the subject or body of the email needs to change?

Hard-coded values are fragile. A better approach is to store your email templates in a data source, even if it only contains one record.

With({
  wthEmailTemplate: LookUp(EmailTemplates, TemplateType="new_signup")},
  Office365Outlook.SendEmailV2(
    gblAuthenticatedUser, 
    wthEmailTemplate.Subject, 
    wthEmailTemplate.Message
  )
)

Now, if the email needs to be changed, you update the data source, not the application logic.

Duplicated Code

While it can be trickier to avoid than in traditional code, duplicate logic is a future maintenance headache.

Imagine two different ways to create comments in an application:

///Main dialog in a stream of comments
With(
    {
        wthNewlyCreatedComment: Patch(
            Comments,
            Defaults(Comments),
            {Comment: txt_hs_comment.Value}
        )
    },
    Collect(
        colComments,
        wthNewlyCreatedComment
    );
    Set(
        gblCommentCount,
        CountRows(colComments)
    )
)
//A different dialog when replying to another's comment
With(
    {
        wthNewlyCreatedComment: Patch(
            Comments,
            Defaults(Comments),
            {Comment: txt_hs_dialogComment.Value}
        )
    },
    Collect(
        colComments,
        wthNewlyCreatedComment
    );
    Set(
        gblCommentCount,
        CountRows(colComments)
    )
)

These two blocks do the same thing. If the logic ever changes, you must remember to update it in both places.

A cleaner approach is to use a user-defined function (UDF) to encapsulate logic that gets reused across your app.

App.Formulas
UpdateComments(comment: Text):Void = 
{
    With(
        {
            wthNewlyCreatedComment: Patch(
                Comments,
                Defaults(Comments),
                {Comment: comment}
            )
        },
        Collect(
            colComments,
            wthNewlyCreatedComment
        );
        Set(
            gblCommentCount,
            CountRows(colComments)
        )
    )
};

And then in each of the locations that need this formula:

//Main dialog in a stream of comments
UpdateComments(txt_hs_comment.Value)

//A different dialog when replying to another's comment
UpdateComments(txt_hs_dialogComment.Value)

As of this writing, user-defined functions in canvas apps support side effects (such as modifying collections or setting variables), but the overall feature is still in Preview.

If UDFs aren't an option for your current use case, a common workaround is to use a hidden button that encapsulates the logic and call it with Select(ButtonName). Just keep in mind: the control must be on the same screen where it's being invoked.

Poor Naming of Controls and Variables

Home Screen
  ButtonCanvas4
  TextCanvas2
  ButtonCanvas1

What's wrong with the scenario above? It is impossible to know what each control is responsible for.

Good naming isn't just a nice-to-have—it's one of the best ways to reduce confusion and improve maintainability, especially in collaborative environments.

Here is an improved version that allows any developer to understand what these controls do.

Home Screen
  txt_hs_userName
  btn_hs_submitForm
  btn_hs_cancelSubmission

In this example, we follow the pattern of:
[control_type]_[screen]_[control responsibility]

This helps make it easy to search for items quickly as well as identify what they do.

Another aspect that naturally lends itself to naming conventions is the use of variables. Canvas apps have various methods for storing data locally.

They include:

Collections (ClearCollect/Collect)
Global Variables (Set)
Local Variables (UpdateContext)
Contextual Variables (With functions)

Each type of variable has a different scoping associated with it. Collections are tables and available throughout your entire application. Global variables are also available throughout the entire application. Variables set using UpdateContext are scoped to the screen on which they are declared. And variables contained within a With function are available only within that function.

It is a good idea to ensure that the variable name accurately reflects the type of variable it represents. For example:

// prefixed with "wth" for a with-function scoped variable
With({wthNewlyCreatedUser: Patch(AppUsers,...)},...)

// prefixed with "ctx" for a screen-scoped contextual variable
UpdateContext({ctxCurrentPostVotes: LookUp(colPostVotes, ....)})

// prefixed with "gbl" for global
Set(gblAuthenticatedUser, LookUp(AppUsers,....))

// prefixed with "col" for a collection
ClearCollect(colUserRoles, LookUp(AppRoles, ...))

Each data storage type is designated by a prefix that indicates its kind, which makes debugging an application easier.

Overloaded Screens and Applications

It can be tempting to keep everything on one screen for simple applications. However, canvas apps can quickly become non-performant if too many controls or too much logic is on a single screen. The recommended limit is no more than 500 controls per app and 300 controls per screen. Using and editing the application can slow down significantly if these limits are exceeded.

One way to prevent this issue is to think more modularly. For example, you may have both administrative and non-administrative tasks within a single application. Instead, you can make two applications, one for admin users and the other for general users.

Another way to avoid these issues in the same application is to build using components. The controls that make up a component don't count individually towards the screen limits and are also a natural way to reduce duplication within and across your applications. Components can be created within an application or as a component library (if your component needs to be used in multiple applications — for example, loaders/spinners and confirmation dialogs).

For more information on components, refer to this article I wrote about building reusable components.

No Version Notes

As the Power Platform ecosystem grows, advanced versioning techniques are being introduced, including the integration of solutions with Git. But even if you don't have that git integration, there is something simple you can do.

When you save an application after any non-trivial change, use the built-in version notes.

This simple habit will make two things much easier:

If you ever need to roll back changes, it becomes much easier to identify the correct version to roll back to.
When using multiple environments (e.g., Dev, Test, and Prod), this can help you identify which version is currently in each environment, as the built-in version numbers may not necessarily match.

To view version notes for a canvas app, select 'View Details' for the app and then select the versions tab.

Invisible Logic

Invisible logic is logic that supports a product, but it is not immediately recognizable. For example, custom APIs and cloud flows can quickly become forgotten if there is no documentation reminding developers that these critical components exist — and what they actually do.

One of the best ways to document a project is by using solutions. Solutions will typically include the majority of a project's assets—often more than 90%—but there are notable exceptions, such as SharePoint lists, Power BI reports, and certain external integrations. Some things a solution often won't or can't include are assets that belong to core or base solutions—for example, generic cloud flows that serve multiple projects or products. Depending on your solution strategy, you may not want to add these to each solution, and they will only exist in a core or base solution. Other things that fall under the umbrella of invisible logic include Power BI assets and Dataflows, along with their respective automation architectures (e.g., how and when a Dataflow gets triggered).

As a best practice, utilize the self-documenting nature of solutions to provide references to all assets, logic, and dependencies that a project uses. Additionally, consider adopting a feature-based documentation practice, where each feature or user story implemented includes basic documentation, including high-level implementation details and any underlying logic. This could be a wiki-like document that allows developers, who may be troubleshooting or extending a feature, a simple way to get oriented before diving into an unfamiliar project.

Denormalized Data Models

Data normalization is a topic of its own, but you don't need to be an expert to get started building robust and scalable data models. In simple terms, data normalization involves grouping similar data elements and eliminating duplication.

Take a look at the following example of the employee table.

Employees Table (Denormalized)

| Employee ID | Name   | Department Name | Department Location |
|-------------|--------|------------------|----------------------|
| 1           | Alice  | HR               | Building A           |
| 2           | Bob    | IT               | Building B           |
| 3           | Carol  | HR               | Building A           |
| 4           | Dan    | IT               | Building B           |
| 5           | Eve    | Finance          | Building C           |

In the above table, we can see the EMPLOYEE table records contain information about the department. Conceptually, this is fine, but the main issue is that the attributes of each record not only describe the employee but also provide details about the department. This type of data is referred to as denormalized data. Denormalized data makes the data model harder to scale and maintain. For example, if the Department Name changes, we must locate every record with that department name and update it accordingly.

Instead, let's examine a more normalized data model that consists of two tables now.

Employees Table (Normalized)

| Employee ID | Name   | Department ID |
|-------------|--------|----------------|
| 1           | Alice  | 1              |
| 2           | Bob    | 2              |
| 3           | Carol  | 1              |
| 4           | Dan    | 2              |
| 5           | Eve    | 3              |


Departments Table

| Department ID | Department Name | Department Location |
|---------------|------------------|----------------------|
| 1             | HR               | Building A           |
| 2             | IT               | Building B           |
| 3             | Finance          | Building C           |

This data model eliminates duplication and simplifies attribute updates for the department, requiring only a single record update to be made. And because each attribute of the EMPLOYEES and DEPARTMENTS tables only describes the primary key of the respective table, this is a normalized data model.

One common misconception among new developers is that more tables are a bad thing. Many believe that fewer data sources are easier to maintain, but that’s not always true. In development, what makes things easier to maintain isn't less of something, but rather how atomic, modular, and dependent-free it is. For example, a few small, pure functions that do just one thing will be easier to maintain than a single side-effect-producing function that does many things.

Don't shy away from normalized data just because it creates more tables. Shy away from data models that won't scale.

One final note: Denormalized data has its place, too, and it's not a bad thing. For example, reporting data is often denormalized and is much more preferred as it makes reporting logic much easier.

Leading with Layout Before Logic

Low code makes it easy to jump in and start building, which is a significant benefit. But this model can also make it very easy to skip important aspects of development, such as requirement gathering, user interface design, and data modeling.

It's perfectly fine to prototype ideas. This is great for quickly determining if something may or may not be feasible. However, you must have the discipline to stop before getting too far along, and take time to plan properly.

For example, consider employing a business logic-first approach. This means that the requirements and core business logic are decided on (and often implemented) before you even start building the user interface. The core principle of this type of development is that, regardless of the interface a user chooses to interact with our data — and remember, a web application is nothing more than an interface to your data — the core business logic should function properly. In this light, a canvas app becomes just an aesthetic wrapper that complements what is hopefully well-designed business logic.

Wrapping Up

Technical debt exists in both traditional and low-code development. Recognizing this debt early, before it begins to accumulate, is critical. Some tips that can reduce and keep technical debt at manageable levels are:

Avoid hard-coded or static data in your app logic
Eliminate duplicated logic with user-defined functions (UDFs)
Use consistent naming conventions for controls and variables
Break overloaded apps into multiple screens or multiple apps
Add version notes to track meaningful changes
Document invisible logic such as flows and APIs
Normalize your data to reduce duplication
Start with business logic—not layout or visuals

Found this helpful? I work at the intersection of low-code and pro-code development, focusing on building performant apps and helping you reclaim your time through thoughtful automation. Explore more at scriptedbytes.com.

Originally published on Scripted Bytes, where I write about scalable low-code development and app architecture.

Using React 19 in Power Apps PCF Components

Brandon Wozniewicz — Fri, 23 May 2025 18:38:50 +0000

While working on a recent PCF (Power Apps Component Framework) project, I experimented with using React 19—and it worked surprisingly well.

If you're considering a similar setup, I wrote a post breaking down what the integration looked like, what worked, and what needed a few tweaks.

In the article, I cover:

Setting up a React 19 + TypeScript environment inside a PCF control
Handling JSX, props, and lifecycle events cleanly
A small tsconfig change that helps VS Code behave as expected

🔗 Read the full tutorial on my blog

If you're building custom components for Power Apps and want more control over structure and UI, this approach is worth exploring.

I'd love to hear how others are structuring modern PCF projects—or what your component stack looks like.

📬 I write at the intersection of low code and pro code over at Scripted Bytes.

DEV Community: Brandon Wozniewicz

What Power Apps Components Can Learn from Your Favorite Café

What is a Component?

How inputs, outputs, and events relate to our coffee shop

The Coffee Shop (Child Component) in Plain Terms

Three simple rules for building scalable components in Power Apps

Rule #1: Take the Order and Follow the Recipe

Rule #2: Make the Same Order the Same Way Every Time

Rule #3: Announce When It's Ready

A Real-World Example: Password Matching

A Better Approach: Reusable and Self-Contained

Summary

How to Assign Dataverse Security Roles at Scale

Table of Contents

Aside: Teams

Canvas Apps Relate / Unrelate Functions

Power Automate with the Relate Rows in Dataverse Action

How it works:

C# Console App: Using the Dataverse SDK

Final Thoughts

How to Reduce Technical Debt in the Power Platform

Table of Contents

Why Technical Debt Is Also a Low-Code Problem

Examples of Technical Debt in a Low-Code Project

Hard-Coded or Static Values in Your Code

Duplicated Code

Poor Naming of Controls and Variables

Overloaded Screens and Applications

No Version Notes

Invisible Logic

Denormalized Data Models

Leading with Layout Before Logic

Wrapping Up

Using React 19 in Power Apps PCF Components

In the article, I cover: