This blog series
PowerApps is a fantastic tool that can allow you to quickly create incredible, powerful, and visually engaging applications to replace your manual business processes. It’s an extremely fun platform to work with that empowers everyone to be able to create professional applications, regardless of background, with an ever-growing collection of incredible features.
The one down side? With the breakneck pace that Microsoft are introducing new functionality, and the myriad of features available, it can be quite daunting trying to find how to start learning to use PowerApps. But never fear! This blog series is designed to take you through my experiences learning PowerApps and provide you with the right steps to take to start your very own PowerApps Journey!
Learning PowerApps with Clarissa – #3 Fundamentals of Functions
In the last instalment we discovered all about Objects and how they could be described as a series of Properties and Behaviours. We dived in depth into Properties and how they have Expected Values of a variety of different Types, and even looked into how to determine what Types different Properties are expecting.
If you read through the previous article you might be wondering where the love is for Behaviours? Well, in today’s post they will take centre stage as we cover Functions, the methods used to describe Behaviours. As always, if you have any questions, suggestions or feel any explanations are unclear, feel free to contact me on Twitter @ClarissaGillin2!
Expected Values of Behaviours
How does a Behaviour differ to a Property? Well, where a Property expects a single value of an acceptable Type, a Behaviour doesn’t expect a value at all, instead it expects an instruction. For example, for our trusty Pen’s ‘On Use’ Behaviour, which we defined as ‘uses ink’ in the previous article, we are telling the pen: “When you get used, start to drain your ink reserve”.
We can think of Behaviours as a When This, Do That.
This means that when we define a Behaviour, we have much less stringent conditions on what we can enter into the formula box, but it can be less clear what you will get out of the result. Rather than being restricted to a single value of a single type, we can have multiple instructions tied to one Behaviour. We can even influence other Behaviours or Properties of the control, or of other controls, by triggering a Behaviour.
Of course, note that the system will not understand if we put “Blue” into the ‘On Use’ Behaviour, since “When you get used, blue” doesn’t make sense as an instruction. Similarly, the system will not understand if we put, “start to drain your ink reserve” into the ‘Ink Colour’ Property. So, it’s important to be able to understand the difference between Properties and Behaviours so that you make sure you are providing the system with the data it expects, otherwise it will get confused, and probably end up confusing you in turn!
The method of defining these instructions is to use Functions. Functions perform actions on given inputs and can provide outputs, and so can basically be thought of as a magic black box. Unlike with other development environments, with PowerApps you don’t have to define and create Functions yourself; instead there is a plethora of pre-defined Functions to make use of. Before we dive into what you can do with all these Functions, I believe it’s important to cover the basic anatomy of a Function. This is something that will quickly become second nature to you, but can be easily taken for granted by those of us who have been using Functions for years.
So, breaking it down, Functions consist of:
- A Name:
- First and foremost, this name provides the user with a sense of what the function is built to do. It will be short and if the name covers two words the words will be written together with no spaces LikeThis
- Arguments (also known as Parameters):
- These are the inputs we give the computer to perform the function on and are written in brackets () after the Name of the function. We call this process of giving the computer inputs as ‘passing’ arguments into functions. Functions can be passed multiple arguments separated by commas like, this. But note that some functions do not need any arguments passed into them at all, although these functions still require the empty parentheses () to be written after the Function Name for the computer to recognise that the function is indeed a function.
- A Return value:
- This is what, if anything, the function outputs after its work is done. Note that not all functions will output a return value, in fact these are the functions we wish to use to describe Behaviours. Functions that return Values can be used to define Properties.
Using Functions’ Return Values
Let’s have a quick look at an example, the RGBA function:
For this function, its Name is “RGBA” which describes the fact that it is a colour function and what format it expects the colour to be given in. The Arguments in brackets are the number indicating the value in the Red channel, the number indicating the value in the Green channel, the number indicating the value in the Blue channel and the number indicating the value in the Alpha channel. The Formula Bar Result View we enabled in the last instalment tells us that this function Returns the Orange colour we are using for our Button, and also lets us know that the Return value is of Type “Color”.
If we start trying to fill out a function in the editor, we’ll actually start to see some really useful tips appear on the screen. Above the formula bar we see two rows appear. The first row displays the definition for the function, in this case “RGBA(red_value, green_value, blue_value, alpha_value)”, which describes how many arguments you need to enter to complete the function and the names of the expected arguments to help you understand what to enter where. The second row displays the name and description of the next argument that needs to be entered.
Functions Without Return Values
In the above case we are using a Function to define a Property, but let’s look at one that defines a Behaviour, like Navigate. This is used on the OnSelect Property of btnNavigate in our example to move the user to a different screen. Navigate, like RGBA, can take multiple different arguments, but does not provide a Return Value and is somewhat special in that it has multiple definitions. Whereas in RGBA each argument was required for the function to work (we couldn’t type RGBA(255) and expect the result to be Red, we have to fully type out RGBA(255, 0, 0, 1) for the function to be complete), in Navigate only one argument is required and optional additional arguments can be passed in to the function to enhance its abilities: Navigate requires only the screen to navigate to as a minimum, but we can also add in an argument that dictates the way in which to transition between the two screens. We can even add further arguments if we’d like. Notice how in the editor this is indicated by the “…” ellipsis after the existing arguments in the definition and that if we add a comma in to our formula bar, the definition alters to tell us what the optional arguments are.
Unlike RGBA, the Navigate function doesn’t have a Return value. This means that it is an acceptable value for the OnSelect Behaviour, since Behaviours do not have values, only carry out instructions. If we think back to the When This, Do That definition of a Behaviour, the sentence “When the button gets pressed, navigate to another screen” makes sense, and so we know this is a valid option. However, sometimes you want to be able to pass information in Behaviours even though you do not have a Return value, and Navigate enables us to do that with the third argument, which allows us to pass across values from one screen to another. Don’t worry too much about the unfamiliar syntax you’ll see in the demo clip below, we’ll cover what’s going on here in detail in upcoming posts!
Functions That Do Not Require Arguments
Both RGBA and Navigate take arguments and either provide us with a value or carry out an instruction based on the arguments they receive. However, some functions don’t require any arguments at all. These are still useful, because of what they return. For example, the User function returns the Record that describes the current user (again think of a Record as a line entry in a table, so User is essentially returning a single row in a table). If the Return value of a function is a complex type, like Record, or an Instance of an Object, we can make reference to the internal Properties of that Object using the same “.” syntax as earlier and so extract valuable information.
While this is just a basic introduction to the world of Functions in PowerApps, I believe knowing the anatomy of a function is a huge help when trying to create, troubleshoot and debug your applications. The most useful part is that it allows you to properly understand the incredibly helpful Function Documentation provided by Microsoft. This documentation can be intimidating for newcomers to PowerApps, but now you should be armed with the ability to make sense of it all! For instance, if we look at the first Function on the list, Abs, we’ll see the documentation gives us a description of the function, the Syntax (including what Type the function is expecting for the arguments) and details of the Return value. Being able to extract this information from the documentation will give you a huge head start in your PowerApps journey!
Now you know about the different Properties and Behaviours of Objects in PowerApps and how to assign Values to them of the correct Expected Types, and can understand the different components of Functions and make the best use of the documentation available to start assigning instructions to the Behaviours of your elements, you’re well on your way to app making! Our next task is to go through some of the bread and butter Functions you’ll be using every day, focusing in on Logic functions in What If? – Logic for PowerApps explained. This knowledge will enable you to start making smart applications that can react to different conditions, so stay tuned!
In the meantime, you’re already primed and ready to have fun assigning values to the Properties of various controls and elements in your own canvas apps and start to have a play with functions, using the documentation to guide you on your way to defining the Behaviours of your elements!
I hope you’ve enjoyed this next step on the way to becoming an App Maker! If you have any questions, want to strike up a conversation, or want regular updates on all things PowerApps, Microsoft Flow and Power BI, make sure to follow me (@ClarissaGillin2), Ben Haynes (@disappointmentb) and @SilversandsLtd on Twitter.
Additionally, I’ll be presenting alongside our other Power Platform experts at our ‘Transforming Business Applications with the Power Platform’ seminar, on 17th September. Please be sure to check that out and register!