DEV Community: Gabriel Follone

Power Apps - Canvas - Onstart How to avoid ruining your application

Gabriel Follone — Tue, 13 Jan 2026 22:26:18 +0000

1. Introduction
2. The OnStart Trap
3. Principles That Keep OnStart Healthy
4. Suggested Structure
5. Practical Tips
6. Final Checklist
7. Conclusion
8. References

1. Introduction

OnStart runs once when the app loads. It is tempting to treat it like a main() function, but that is where performance and maintainability regress. The goal is to keep OnStart as a thin orchestration layer and push real logic into the formula bar (named formulas, UDFs, tables, and styles).

Microsoft guidance for large canvas apps explicitly recommends using App.Formulas instead of App.OnStart and splitting long formulas into reusable parts. That direction is exactly what this article reinforces (see Build large and complex canvas apps).

2. The OnStart Trap

When OnStart becomes a dumping ground, apps slow down and become fragile. Avoid these patterns:

Do not place core business logic in OnStart. Define UDFs and named formulas and call them from screens or controls.
Do not load large datasets at startup. Load only what the first screen needs and defer the rest.
Do not build long, monolithic formulas in OnStart. Split logic into named formulas and UDFs (see Build large and complex canvas apps).
Do not call connectors inside loops. This multiplies network calls and kills load time.
Do not mix unrelated responsibilities. Separate parameters, caching, user context, and UI defaults.
Do not use OnStart as a hidden workflow engine. This breaks reusability and makes testing harder.
Do not rely on screen state. Screen-specific setup belongs in Screen.OnVisible or screen-level UDFs.

3. Principles That Keep OnStart Healthy

Use these principles to keep OnStart small and safe:

Thin Orchestration Only
- OnStart should call setup steps, not implement them.
- Keep reusable logic in App.Formulas and UDFs.
Deterministic and Idempotent
- Running OnStart twice should not corrupt state or create duplicates.
Fast First Screen
- Load only what is required for the first screen to render (see Overview of creating performant apps).
Separation of Concerns
- Keep environment/params, collections, user context, and theme settings in distinct blocks.
Concurrent Only For Independent Tasks
- Use Concurrent only when operations are truly independent (see Efficient calculations).

4. Suggested Structure

/*-----------------------------------------------OnStart-----------------------------------------------*/
// Flow response and parameters
With(
    { coFlow: 'SomeFlow'.Run() },
    Set(vsFlowValue, coFlow.result)
);

// Deeplink routing (task focus)
If(
    !IsBlank(Param("Source")),
    Switch(
        Param("SomeParameter"),
        "TaskA",
        /* setup for TaskA */,
        "TaskB",
        /* setup for TaskB */,
        Blank()
    )
);

// Global defaults and parameters
Concurrent(
    Set(vsParamScreen, Param("Screen")),
    Set(viParamItemId, Value(Param("ItemID")))
);

// Build month/period lists
ClearCollect(
    colPeriodList,
    /* data builder logic */
);

// Optional data enrichment (only if needed)
If(
    RoundUp(Month(Now()) / 3, 0) = 1,
    Collect(colPeriodList, /* additional rows */)
);

// Collections cache (first screen only)
ClearCollect(
    colCache,
    ShowColumns(SomeDataSource, /* required columns */)
);

/*-----------------------------------------------End OnStart-----------------------------------------------*/

5. Practical Tips

Use App.Formulas to split logic and keep OnStart readable (see Build large and complex canvas apps).
Prefer named formulas for read-only values like constants, configuration, and lookups (see Get started with formulas in canvas apps).
Use explicit column selection like ShowColumns when caching collections to reduce payload (see Efficient calculations).
Prefer delegable query patterns such as server-side views and StartsWith/Filter to avoid local loops (see Optimized query data patterns).
Cache only what is reused on multiple screens. If a collection is used on a single screen, load it there.
Avoid Patch/SubmitForm in OnStart. Side effects at startup are hard to debug.
Document the intent of each block with short comments.

6. Final Checklist

Before shipping, verify:

OnStart runs fast and does not load unnecessary data.
Logic is grouped into clear sections with comments.
Business rules live in the formula bar (UDFs, named formulas).
Screen-specific init is in Screen.OnVisible, not OnStart.
Concurrent is used only for independent work.
There are no hidden side effects or data writes on startup.

7. Conclusion

Keeping OnStart lean makes your app faster, easier to maintain, and easier to scale. Treat it as a launcher, not as the place where the app truly lives. The formula bar is where the app logic should grow.

8. References

Official Documentation

Performance and Optimization

Power Apps - Canvas - Code Reusability How to Do It

Gabriel Follone — Sat, 05 Jul 2025 02:18:28 +0000

1. Introduction
2. Challenge
3. How to Solve It?
- Buttons
- Custom Components and Enhanced Component Properties
- User Defined Functions
- Safely Manipulating Items
- Software Development Principles
4. Conclusion
5. Recommendations by Scenario
6. Important Notes
7. References

1. Introduction

As an application grows, it's natural to look for ways to optimize development. Code reusability has always been an applicable concept in Power Apps, although on smaller scales and with greater complexity in the past. Currently, it's more accessible and effective. This article will present several examples of how to reuse logic in your Canvas application, as well as discuss when it's appropriate to apply these techniques.

For this, let's start with a simple and very common scenario in the daily life of those who create apps with this technology.

2. Challenge

Let's say someone asked for a screen to register new people on the team and the screen needs to have a form with 3 text fields, a reset button, a save button, and a table on the side where it's possible to view all team members. Every time the user enters the screen, it needs to reload the users table and reset the input controls, the reset button whenever clicked needs to reload the table and reset the input controls, and the save button needs to update the team members table, simple right?!

So let's go to the screen without logic and we should have something like this:

Now let's create the logic to reset the input controls and we should have something like this:

//Reset Fields
Reset(tiExample1Field_1);
Reset(tiExample1Field_2);
Reset(tiExample1Field_3);

Creating the logic to reload the table we have something like this:

//Reload Collection
ClearCollect(colTeam, tbTeam)

If we don't follow best practices, we'll end up adding this logic repeatedly in different controls, meaning we'll have the same logic in the screen's OnVisible and in the reset button's OnSelect:

/*==============OnVisible==============*/
//Reload Collection
ClearCollect(colTeam, tbTeam);
//Reset Fields
Reset(tiExample1Field_1);
Reset(tiExample1Field_2);
Reset(tiExample1Field_3);

/*==============OnSelect==============*/
//Reload Collection
ClearCollect(colTeam, tbTeam);
//Reset Fields
Reset(tiExample1Field_1);
Reset(tiExample1Field_2);
Reset(tiExample1Field_3);

3. How to Solve It?

Now the discussion starts to get serious, after all, currently the best way to do this is still in preview and the others we have available are workarounds, and what are they?

Buttons

We have the option to add all of this to an invisible button on the screen and make the screen's OnVisible properties and the reset button's OnSelect be a Select() to this invisible button. This way we ensure maintenance in a single place, but what are the limitations of this approach? The Select() doesn't work with controls from other screens and doesn't have native support for parameters, meaning if we have logic that is used several times by different controls and events on the same screen and we don't need to pass dynamic values to this logic, this option becomes very interesting and doesn't require activating any preview features.

Custom Components and Enhanced Component Properties

The most viable option currently that doesn't need to activate preview features (yes, enhanced component properties are GA), what are the pros and cons? It brings the same gains as reusability with buttons and still supports parameters (and even allows optional parameters), we can call properties of type event, action, and function from different screens. The downside is just that it's not so easy to use and especially for those who aren't used to real development might not understand very well how to use or where to apply it, but here's an example:

In this example we don't need to pass any parameters, but we need to change the state of items that are on the screen so we need to activate the component's Access app scope and with that our property needs to be of type action:

Then copy and paste the logic from the invisible button's OnSelect from the previous step into the property we just created, add this custom component in a way that's not visible to the user on the team form screen and replace the Select(buExample1Invisible) with ccFunctionsTeam_1.fxReloadAndResetTeam() and voilà!

User Defined Functions

The best option, but still not in GA are definitely the UDFs (even though they still don't support optional parameters, they now support behavior functions), and why? Simplicity! It's better than working with Enhanced Component Properties because we can declare it directly in the formula bar, meaning we don't need to create components and add them to the screen, which makes the solution much simpler, elegant, and easy to understand. And how would this look in practice?

First, copy and paste to the formula bar in the UDFs section the code snippet below (if you don't know what the UDF section is, read my other article about Power Apps - Canvas - Formula Bar Anatomy - DEV Community):

udfReloadAndResetTeam() = {
    //Reload Collection
    ClearCollect(colTeam, tbTeam);
    //Reset Fields
    Reset(tiExample1Field_1);
    Reset(tiExample1Field_2);
    Reset(tiExample1Field_3);
};

And the solution would look like this:

Well, from here I assume I no longer need to explain the benefit of all this and the examples will now always start from using UDFs to make this article a bit more practical.

In our challenge so far we've only solved the request regarding the reset button's OnSelect and the Team form screen's OnVisible, but we still need the Save control and how can we do this following all these best practices I'm talking about?

Safely Manipulating Items

So far the expression we were reusing was very simple, it had no parameters or anything dynamic. Now let's create a UDF that accepts parameters, but not only that, let's declare types to make our application resistant to unexpected bugs. And in this example we'll create a static named formula with a default value for our team collection just to make it easy to explain.

Copy and paste in your formula bar in the table section the named formula below:

tbTeam = [
    {ItemId: 1, ItemPersonName: "John Doe", ItemPersonMail: "jdoe@contoso.com", ItemPersonRegion: "NA"},
    {ItemId: 2, ItemPersonName: "Gabriel Follone", ItemPersonMail: "gfollone@contoso.com", ItemPersonRegion: "SA"}
];

Now copy and paste in the UDTs section the type below:

tpTeamMember := Type({
    ItemId: Number,
    ItemPersonName: Text,
    ItemPersonMail: Text,
    ItemPersonRegion: Text
});

And finally paste in the UDF section our expression that will insert the values into the collection:

udfPostMember(ParamMember: tpTeamMember) = {
    Patch(colTeam, 
        Coalesce(LookUp(colTeam, ItemId = ParamMember.ItemId), {}),
        {
            ItemId: (Last(colTeam).ItemId + 1),
            ItemPersonName: ParamMember.ItemPersonName,
            ItemPersonMail: ParamMember.ItemPersonMail,
            ItemPersonRegion: ParamMember.ItemPersonRegion
        }
    )
};

Now the implementation of this becomes quite simple, just add to the save button's OnSelect the following expression:

udfPostMember(
    {
        ItemPersonName: tiExample1Field_1.Value,
        ItemPersonMail: tiExample1Field_2.Value,
        ItemPersonRegion: tiExample1Field_3.Value
    }
)

Software Development Principles

And now let's say a new request comes up: after saving, the input controls need to be reset. But we have a problem now, because our UDF that controls the reset of the form controls also resets the collection! And here comes the SRP (Single Responsibility Principle) from SOLID. This principle makes it clear that a function should be responsible for only one thing within our system, meaning, let's create a UDF for resetting the controls, another for resetting the collection, resulting in:

udfReloadTeamData() = {
    //Reload Collection
    ClearCollect(colTeam, tbTeam);
};

udfResetTeamForm() = {
    //Reset Fields
    Reset(tiExample1Field_1);
    Reset(tiExample1Field_2);
    Reset(tiExample1Field_3);
};

But now how does the implementation look? In the save button's OnSelect right below the udfPostMember do I call udfResetTeamForm or add udfResetTeamForm inside udfPostMember? If you thought neither, congratulations! Why are neither options good options?

Scenario 1: Add the call to both UDFs directly in OnSelect

First, this option is much better than the second, but here we're learning about reusability and best practices for all of this, meaning, leaving all the logic in a single control having the option to leave it encapsulated in the formula bar is not the best decision. This reduces the reusability options of the logic, after all, even though it's possible to use Select() on this button, if I need to use this outside this screen it would no longer be possible.

Second, it decreases testability, after all it's much easier to test encapsulated logic.

Third, clarity and maintainability: having this directly in the button's OnSelect is harder to find and if I have this same logic calling 2 UDFs in different places and the execution order is changed, I would have to change it in all places where this logic is used.

Scenario 2: Add the call to udfResetTeamForm inside udfPostMember

If you understood the explanation about SRP you must have already realized that opting for this scenario makes us go against this principle, after all by doing this we are increasing the coupling between the UDFs, this means that one will depend on the other. If the way to reset the form changes, or if you want to use udfPostMember in a context where the reset is not necessary, you'll have to modify the insert function. And obviously when coupling increases, flexibility decreases and you lose the option to decide when and how the form should be reset. The reset becomes a mandatory consequence of the insert.

Best Scenario - Scenario 3: Create a UDF that orchestrates the other two

With this you maintain the SRP principle, keep coupling low, increase reusability within the app and make the application's operation more readable and easier to understand. Win-win-win!

udfSaveAndResetForm(ParamMember: tpTeamMember) = {
    udfPostMember(ParamMember);
    udfResetTeamForm();
};

4. Conclusion

Once again showing that principles long disseminated in software development can be easily applied to low-code tools. Even though we are limited to what the tool's controls offer us (if we don't use PCFs), it's easy to apply everything I explained - it just requires discipline and minimal planning before implementation.

Method	Pros	Cons
Invisible Buttons	• Doesn't require preview features • Simple to implement • Works immediately • Familiar to beginners • Doesn't affect performance	• `Select()` doesn't work between screens • Doesn't support parameters natively • Can pollute the screen with invisible controls • Considered a "workaround"
Custom Components (Enhanced Component Properties)	• Is in GA • Supports parameters (including optional) • Works between different screens • Shareable via component library • Typed properties (Action, Event, Function) • Reusable between apps • Professional solution	• Requires more technical knowledge • More complex initial setup • Steeper learning curve • Can increase app size • Harder to debug
User Defined Functions (UDFs)	• Direct declaration in formula bar • Cleaner and more intuitive syntax • Supports behavior functions (Set, Collect, Reset) • No need to add extra controls • Facilitates unit testing • Better code organization • Optimized performance	• Still in Preview (not GA) • Doesn't support optional parameters • Can't create local variables • Some technical limitations • May change before GA • Requires manual activation • Not shareable between apps (yet)

5. Recommendations by Scenario

Scenario	Recommended Method
Simple app, single screen logic	Invisible Buttons
Enterprise app, multiple screens	Custom Components
App in development, technical team	UDFs (with caution)
Shared library between apps	Custom Components
Rapid prototyping	Invisible Buttons
Production with long-term support	Custom Components

6. Important Notes

UDFs: Still in preview, not in GA (Generally Available)
Enhanced Component Properties: Are in GA and ready for production
UDFs syntax with behavior functions: Use braces {} for functions with behavior functions
UDFs have limitations: Don't support optional parameters and have some technical restrictions
UDTs are still an Experimental feature

7. References

Official Documentation

Blogs and Articles

Performance and Optimization

Power Apps - Canvas - Formula Bar Anatomy

Gabriel Follone — Wed, 16 Apr 2025 13:05:21 +0000

1. Introduction
2. Basic Structure
- App Values
- UDTs (User Defined Types)
- Tables
- UDFs (User-Defined Functions)
- Assets
- Styles
7. Conclusion
8. References

1. Introduction

Code reusability is relatively simple in traditional programming. Concepts like DRY (Don't Repeat Yourself) have existed for a long time, but in Power Platform, this was only possible with considerable effort. Now, this reality has changed with improvements in the formula bar, and that's what we'll explore.
As we add more elements to the formula bar, it becomes increasingly difficult to maintain consistency. That's why I've been organizing it in a specific way that I'd like to share with you.

2. Basic Structure

App Values

This section contains basic information about the application and global variables that will be used throughout the app.

/*-----------------------------------------------App Values-----------------------------------------------*/
AppName = "Power Track";
AppVersion = "1.0.0.0";
AppUser = udfGetUserDetails(User().Email);

// Environment Variables
evjsTheme = LookUp('Environment Variable Values', 'Environment Variable Definition'.'Display Name' = "evjsTheme").Value;
/*-----------------------------------------------App Values-----------------------------------------------*/

UDTs

User Defined Types (UDTs) help structure complex data and improve typing in the application.

/*-----------------------------------------------UDTs-----------------------------------------------*/
// Custom types to structure Office 365 user data
tpUser := Type(
    {
        AccountEnabled: Boolean,
        BusinessPhones: [{Value: Text}],
        City: Text,
        CompanyName: Text,
        Country: Text,
        Department: Text,
        DisplayName: Text,
        GivenName: Text,
        Id: Text,
        JobTitle: Text,
        Mail: Text,
        MailNickname: Text,
        OfficeLocation: Text,
        PostalCode: Text,
        Surname: Text,
        TelephoneNumber: Text,
        UserPrincipalName: Text,
        mobilePhone: Text
    }
);

// Custom type to structure the color theme
tpThemePalette := Type(
        {
            palette: {
                themePrimary: Text,
                themeLighterAlt: Text,
                themeLighter: Text,
                themeLight: Text,
                themeTertiary: Text,
                themeSecondary: Text,
                themeDarkAlt: Text,
                themeDark: Text,
                themeDarker: Text,
                neutralLighterAlt: Text,
                neutralLighter: Text,
                neutralLight: Text,
                neutralQuaternaryAlt: Text,
                neutralQuaternary: Text,
                neutralTertiaryAlt: Text,
                neutralTertiary: Text,
                neutralSecondary: Text,
                neutralPrimaryAlt: Text,
                neutralPrimary: Text,
                neutralDark: Text,
                black: Text,
                white: Text
            }
        }
    )
;
/*-----------------------------------------------UDTs-----------------------------------------------*/

Tables

This section contains static table definitions and logic for data manipulation.

/*-----------------------------------------------Tables-----------------------------------------------*/
// Definition of static tables and data manipulation

// Screen inventory and access control based on named formulas
tbScreens = [
    {ItemId: 1, ItemDisplayName: "Home", ItemScreen: Home}
];

// Table used for navigation components such as a tablist for example
tbNavigation = [
    {ItemId: 1, ItemDisplayName: "Home", Visible: true, ItemTargetScreen: LookUp(tbScreens, ItemId = 1).ItemScreen }
];

// Example of defining a table for use within the app
/*
tbFeedBack = ShowColumns([Table],
        'Created By', //Person Standard
        Rating, //Number
        Message //Multiple Line of Text
    )
;
*/
/*-----------------------------------------------Tables-----------------------------------------------*/

UDFs

User-Defined Functions (UDFs) allow encapsulating reusable logic, making the code cleaner and easier to maintain.

/*-----------------------------------------------UDFs-----------------------------------------------*/
// Reusable functions that simplify logic
udfGetUserDetails(ParamSearch:Text):tpUser =
    If(!IsBlank(ParamSearch),
        First(Office365Users.SearchUserV2({searchTerm: ParamSearch}).value)
    )
;

udfConvertSvg(ParamSvgValue:Text):Text = "data:image/svg+xml;utf8, "&EncodeUrl(ParamSvgValue);
/*-----------------------------------------------UDFs-----------------------------------------------*/

Assets

In this section, icons and other visual elements used in the application are defined.

/*-----------------------------------------------Assets-----------------------------------------------*/
// Definition of icons and visual elements

svgHomeIcon = $"<svg xmlns='http://www.w3.org/2000/svg' height='24px' viewBox='0 -960 960 960' width='24px' fill='000000'><path d='M240-200h147.69v-235.38h184.62V-200H720v-360L480-741.54 240-560v360Zm-40 40v-420l280-211.54L760-580v420H532.31v-235.38H427.69V-160H200Zm280-310.77Z'/></svg>";

// Another option here is to make the svg colors dynamic

svgHomeIconDynamic(ParamColor:Text):Text = $"<svg xmlns='http://www.w3.org/2000/svg' height='24px' viewBox='0 -960 960 960' width='24px' fill='{ParamColor}'><path d='M240-200h147.69v-235.38h184.62V-200H720v-360L480-741.54 240-560v360Zm-40 40v-420l280-211.54L760-580v420H532.31v-235.38H427.69V-160H200Zm280-310.77Z'/></svg>";

//To use it is simple, in the image value of an image control you pass the following function udfConvertSvg(svgHomeIconDynamic("#000000"))
/*-----------------------------------------------Assets-----------------------------------------------*/

Styles

Here, visual definitions such as colors, fonts, and component styles are centralized.

/*-----------------------------------------------Style------------------------------------------------*/
// Standardized colors, fonts, and visual elements

// Application theme based on environment variable
Theme = AsType(ParseJSON(evjsTheme), tpThemePalette);

// Fonts
Fonts = {
    Bold        : "Sans Black",
    Semibold    : "Sans Medium",
    Normal      : "Sans",
    Lighter     : "Sans Light"
};

// Text colors
FontColors = {
    Active      : ColorValue("#000000"),  // Active, selected states - using neutralPrimary
    Primary     : ColorValue("#32ba23"),  // Titles, headers - using themePrimary
    Secondary   : ColorValue("#373737"),  // Secondary text, subtitles - using neutralSecondary
    Disabled    : ColorValue("#595959"),  // Disabled text - using neutralTertiary
    WarnLight   : ColorValue("#D11F1F")   // Error text - kept as is because there's no equivalent in the palette
};

//FontSettings
FontSettings = {
    H1: {
        Bold:    { Font: Fonts.Bold,   Size: 24, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Primary    },
        Normal:  { Font: Fonts.Normal, Size: 24, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Primary    },
        Lighter: { Font: Fonts.Normal, Size: 24, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Secondary  }
    },
    H2: {
        Bold:    { Font: Fonts.Bold,   Size: 18, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Primary    },
        Normal:  { Font: Fonts.Normal, Size: 18, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Primary    },
        Lighter: { Font: Fonts.Normal, Size: 18, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Secondary  }
    },
    H3: {
        Bold:    { Font: Fonts.Bold,   Size: 16, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Primary    },
        Normal:  { Font: Fonts.Normal, Size: 16, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Primary    },
        Lighter: { Font: Fonts.Normal, Size: 16, Lineheight: 1.3, Fontweight: FontWeight.Normal, Color: FontColors.Secondary  }
    }
    ...
};

// Component definition example
Components = {
    Button: {
        Primary: {
            AutoDisableOnSelect: false,
            BorderColor: RGBA(0,0,0,0),
            BorderThickness: 0,
            Color: ColorValue(Theme.palette.white),
            DisabledBorderColor: ColorValue(Theme.palette.neutralLighterAlt),
            DisabledColor: FontColors.Disabled,
            DisabledFill: ColorValue(Theme.palette.neutralLight),
            Fill: ColorValue(Theme.palette.themePrimary),
            FocusedBorderColor: RGBA(0,0,0,0),
            FocusedBorderThickness: 3,
            Font: FontSettings.P.Bold.Font,
            FontWeight: FontSettings.P.Bold.Fontweight,
            HoverBorderColor: RGBA(0,0,0,0),
            HoverColor: ColorValue(Theme.palette.white),
            HoverFill: ColorValue(Theme.palette.themeDark),
            PressedBorderColor: ColorValue(Theme.palette.neutralPrimary),
            PressedColor: ColorValue(Theme.palette.white),
            PressedFill: ColorValue(Theme.palette.themeDarker),
            RadiusBottomLeft: 5,
            RadiusBottomRight: 5,
            RadiusTopLeft: 5,
            RadiusTopRight: 5,
            Size: FontSettings.P.Bold.Size
        }
        //...
    }
};
/*-----------------------------------------------Style------------------------------------------------*/

7. Conclusion

In summary, the concepts applied here are old; there's nothing about reinventing the wheel, but for Power Apps, they are relatively new. In other words, we just need to apply what already works here too.

Note: The structure above is just how I organize my formula bar. You are free to organize it as you wish, but just a tip: if you want to create a UDF that uses a table, the UDF must be below the table, which is why I organize UDT > Table > UDF.

DEV Community: Gabriel Follone

Power Apps - Canvas - Onstart How to avoid ruining your application

Table of Contents

1. Introduction

2. The OnStart Trap

3. Principles That Keep OnStart Healthy

4. Suggested Structure

5. Practical Tips

6. Final Checklist

7. Conclusion

8. References

Official Documentation

Performance and Optimization

Power Apps - Canvas - Code Reusability How to Do It

Table of Contents

1. Introduction

2. Challenge

3. How to Solve It?

Buttons

Custom Components and Enhanced Component Properties

User Defined Functions

Safely Manipulating Items

Software Development Principles

4. Conclusion

5. Recommendations by Scenario

6. Important Notes

7. References

Official Documentation

Blogs and Articles

Performance and Optimization

Power Apps - Canvas - Formula Bar Anatomy

Table of Contents

1. Introduction

2. Basic Structure

App Values

UDTs

Tables

UDFs

Assets

Styles

7. Conclusion

8. References