Power Apps- Moving Away From Inline Code

Source: Dev.to

1. Inline Code

What it looks like

You can embed JavaScript directly in an element:

Click Me

Or, in Power Apps, you can write a formula right on a property (e.g., OnSelect).

Why it’s popular

• Immediate context – The code lives next to the component it affects, making it easy to understand at a glance.

  If(vsText = "Hello World", RGBA(189, 178, 176, 1), Color.Red)

  

• Portability – Copy‑pasting a component between apps brings its logic with it.

Trade‑offs

Reviewing code

When every formula is inline, there is no single “global view” of the app’s logic. You end up hunting through many screens and controls, seeing only tiny snippets at a time.

FYI: I built a web app that extracts all the code from a Canvas app into one document – see it at .

Reusing code

Good code is reusable. Inline formulas force you to duplicate logic across controls.

Example: a SQL‑query connector needed in seven different buttons (New Search, Next Page, …). Each button contained the same block of code, only the inputs differed.

When to use inline code

If the code does more than one logical step (e.g., patch + reset + update), move it to a reusable block.

---

2. User‑Defined Functions (UDF) & Behaviour UDFs

Power Apps now supports App Formulas (also called UDFs). A Behaviour UDF (Microsoft’s term) is essentially a sub‑routine – it performs actions but does not return a value.

Differences

Simple examples

UDF – returns a value

AddOne(num : Number) : Number = (
    num + 1
)

Behaviour UDF – performs an action

AddToVar(num : Number) : Void = {
    Set(viNum, viNum + num)
}

The first increments the supplied number and returns it; the second updates a global variable.

Creating them

Both are defined in App → Formulas:

The syntax differs slightly:

FunctionName( inputName : InputType ) : OutputType (
    // Your code here
)

UDFs use parentheses () for the body, while Behaviour UDFs use curly braces {} to indicate they perform actions without returning a value.

---

3. When to Use UDFs / Behaviour UDFs

---

4. Functions in Data‑versus‑Flows

(Placeholder for any additional discussion about using functions inside Power Automate flows or Dataverse‑side logic.)

TL;DR

• Inline – Quick, context‑specific, but hard to review and reuse.
• UDF / Behaviour UDF – Centralised, reusable, and easier to maintain; use them for any logic that is repeated or that would make an inline formula unwieldy.

By applying these guidelines, your Power Apps will stay readable, maintainable, and scalable—just like moving JavaScript from inline “ handlers to external script files.

---

5. Example UDS

SubroutinenName( inputName:inputType ) : Void {
    
}

---

6. Optional & Multiple Inputs

AddTogether(num:Number, num2:Number) : Number = (
    num + num2
);

---

7. Simple UDS Example

AddOneToVar() : Void = {
    Set(viNum, viNum + 1);
};

---

8. When to Use UDF vs. UDS

As you can see, although UDFs are super useful, they won’t dramatically change the way we code our apps because the use‑case is relatively small. UDSs, however, are far more powerful because we can follow the path pioneered by web developers.

8.1 When to use UDF/UDS

My hot take: we should be using UDSs a lot more. Looking at the two conditions for using inline code, everything else should be moved to the Formulas bar and called as a UDS.

• Reuse – If you plan to reuse the code, make it a UDS.
• Complexity – If an event property contains multiple Power FX functions, make it a UDS.

There are always shades of gray. For example, should the following be moved to a UDS?

UDS() : Void = {
    Patch(dummyData, {ID:1}, {Title:"test1"});
    ResetForm(Form1);
};

It performs multiple Power FX functions but is only two lines long. For readability and a clear standard, I would move it to a UDS.

Key Caveats

• Naming – Use descriptive names; include the component name if the function isn’t reusable.
• Comments – If reusable, list the components that use it in comments.

---

9. Functions in Dataverse & Flows

Dataverse Functions

• Run on the server using Power FX.
• Provide reusability via a simple API URL, callable from other apps, flows, and pro‑code solutions.

Considerations

• Still buggy; Microsoft’s focus appears to be waning.
• Requires a Premium license.
• Max runtime: 2 minutes.
• Synchronous – the caller must wait for completion.

Use Dataverse functions only for niche scenarios where the same code must run across multiple platforms.

Power Automate Flows

• Adds a non‑Power FX technology layer, but every Power App developer can use Power Automate.
• Slower than native Power FX, but offers:
  • Access to many connectors.
  • Non‑user (service) connections.
  • Delegation – the app can continue while the flow runs in the background.

Typical Use Cases

• Long‑running jobs that shouldn’t block the UI.

For more details, see my blogs:

• Instant Dataverse Functions & Low‑Code Plug‑ins
• Power Apps – Client or Server Side?
• How to – Power Apps Getting Polling Update from File Upload

---

10. Final Thoughts

The hot take: move your code out of inline expressions and into blocks (UDSs). I expect push‑back, and that’s fair, but consider:

• It’s not an all‑or‑nothing rule – there are shades of gray.
• Change takes time, but once you get used to it, readability and maintainability improve.
• Pro‑code solutions often handle the heavy lifting for us.

---

😎 Subscribe to David Wyatt