Common PowerApps Utility Functions: A Quick Overview with Use Cases

Spend enough time in Power Apps and you notice a pattern: the difference between an app that works and one that’s actually maintainable usually comes down to how well you’re using the utility functions — the formulas handling data caching, validation, formatting, and navigation behind the scenes. This is a working reference for the ones that come up constantly, grouped by what they’re actually for.

In this post: Data handling · Conditional and logical · Text and formatting · Date and time · Validation · Error handling · Navigation and app state · Loading several data sources without waiting on each one · Best practices · When would you actually use this? · A combined example · Related reading

Data handling

Collect() / ClearCollect() store data locally in a collection — useful for caching a data source’s contents on app start so you’re not re-querying it constantly:

ClearCollect(colEmployees, EmployeesList)

Patch() creates or updates a record with explicit control over which fields get set — use it instead of SubmitForm whenever you need logic around what actually gets written:

Patch(EmployeesList, Defaults(EmployeesList), {
    Title: "John Doe",
    Department: "IT"
})

LookUp() returns a single matching record, Filter() returns every matching record:

LookUp(EmployeesList, Email = User().Email)
Filter(EmployeesList, Department = "IT")

Conditional and logical

// If() -- basic branching
If(IsBlank(TextInput1.Text), "Required", "Valid")

// Switch() -- cleaner than nested If() for more than two branches
Switch(
    Dropdown1.Selected.Value,
    "High", Color.Red,
    "Medium", Color.Orange,
    "Low", Color.Green
)

// Coalesce() -- first non-blank value, avoids nested IsBlank() checks
Coalesce(TextInput1.Text, "N/A")

Text and formatting

// Concat() -- joins a column across a table into one string
Concat(Gallery1.AllItems, Title, ", ")

// Upper() / Lower() / Proper() -- case conversion
Upper("john doe") // "JOHN DOE"

// Text() -- format dates, numbers, currency to a specific pattern
Text(Now(), "yyyy-mm-dd")

Date and time

Now()               // current date and time
Today()             // current date, no time component
DateAdd(Today(), 7) // 7 days from today (unit defaults to Days)
DateDiff(StartDate, EndDate, Days)

Validation

IsBlank(TextInput1.Text)
IsMatch(TextInput1.Text, Email) // e.g. validating an email format

Error handling

Worth calling out directly, since both Patch() examples earlier in this post write to a data source with no error checking at all — a real gap, since a failed Patch() doesn’t throw a visible error by default, it just silently doesn’t save. IfError() wraps an expression and branches on whether it failed, with FirstError.Message giving the actual reason:

IfError(
    Patch(EmployeesList, Defaults(EmployeesList), { Title: "John Doe", Department: "IT" }),
    Notify("Error saving: " & FirstError.Message, NotificationType.Error),
    Notify("Record saved successfully", NotificationType.Success)
)

The order matters and is easy to get backward: the failure branch comes right after the expression being checked, the success branch comes last. IsError() is the lighter-weight sibling when you just need a true/false check rather than the actual error message — useful inside an If() condition rather than as the primary wrapper. Treat any Patch() or Collect() writing to a real data source as needing this wrapper by default, not just the ones where a failure would be obviously noticed.

Navigation and app state

Navigate() moves between screens. Set() and UpdateContext() both hold state, but at different scope — Set() creates a global variable visible across the whole app, UpdateContext() creates a context variable scoped to the current screen:

Navigate(Screen2, Fade)

Set(varUserName, User().FullName)        // global
UpdateContext({locLoading: true})        // screen-scoped

Loading several data sources without waiting on each one

The combined example further down chains a ClearCollect() and a LookUp() with semicolons — fine there, since the second genuinely depends on the first’s result. But chaining independent data calls with semicolons the same way is a real, common performance mistake: each one waits for the previous to finish before starting, so three unrelated one-second calls in OnStart add up to three seconds, even though nothing about them actually requires that order.

// Sequential -- roughly 3 seconds total if each call takes ~1 second
ClearCollect(colEmployees, EmployeesList);
ClearCollect(colDepartments, DepartmentsList);
ClearCollect(colProjects, ProjectsList);

// Concurrent -- roughly 1 second total, limited by the slowest single call
Concurrent(
    ClearCollect(colEmployees, EmployeesList),
    ClearCollect(colDepartments, DepartmentsList),
    ClearCollect(colProjects, ProjectsList)
)

Concurrent() runs every formula passed to it at the same time rather than one after another, and the app waits only for the slowest one to return — worth reaching for specifically in App.OnStart or Screen.OnVisible, where several unrelated data sources commonly get loaded together. The real constraint: only use it for formulas that are genuinely independent of each other’s results. Anything that writes — Patch(), Collect() against a live data source with side effects, SubmitForm() — needs to stay sequential and outside Concurrent(), since running writes in parallel risks race conditions the semicolon chain would have avoided by accident.

Best practices

Break nested formulas into named variables rather than chaining functions three or four deep — it costs a line, but the next person (often you, in six months) can actually follow it.
Use collections deliberately, not by default. They’re loaded into memory client-side, so caching an entire large list “just in case” can become its own performance problem.
Watch for delegation limits. Filter() and LookUp() don’t delegate fully against every data source — SharePoint in particular has real gaps (certain operators, nested conditions), and a non-delegable query silently caps at 500 or 2,000 records instead of erroring. This is the single most common “why is my data missing” bug in Power Apps.
Standardize prefixes so variable scope is obvious at a glance: col for collections, var for global variables, loc for context variables.

The most common “why is my data missing” bug in Power Apps isn’t a formula error — it’s a delegation limit silently capping results at 500 or 2,000 records.

When would you actually use this?

Form validation before submit — catch blank required fields with a single condition instead of letting a bad Patch() fail silently:
If(IsBlank(NameInput.Text) || IsBlank(EmailInput.Text), Notify("All fields required", NotificationType.Error))
Role-based UI — show or hide controls based on who’s logged in:
If(User().Email = "admin@company.com", true, false)
Loading indicators around a slower action, so the UI doesn’t look frozen:
UpdateContext({locLoading: true}); /* action */ UpdateContext({locLoading: false})
Shaping data for display without changing the source — adding a computed column just for the UI:
AddColumns(EmployeesList, "FullName", FirstName & " " & LastName)

A combined example

Several of the functions above together — cache the data, identify the current user, and route accordingly:

ClearCollect(colEmployees, EmployeesList);

Set(varCurrentUser,
    LookUp(colEmployees, Email = User().Email)
);

If(
   IsBlank(varCurrentUser),
   Notify("User not found", NotificationType.Error),
   Navigate(HomeScreen)
);

Power Apps Model-Driven Apps vs Canvas Apps — these functions are Canvas-side formulas; Model-Driven apps handle most of this differently.
M365 Dataverse or SharePoint List as Data Source — the delegation limits mentioned above hit much harder against SharePoint than Dataverse, which is one real factor in that choice.

Hope that’s useful for your setup. Let me know in the comments.