Not after hours, or after dozens of turns. Sometimes after just a handful of exchanges. And the reason for this isn’t exactly clear, mainly due to Microsoft’s lack of transparency around a fundamental question: how much of the model’s context window is actually available for your conversation?.

What the Generative Orchestrator Does

For those unfamiliar, the generative orchestrator is the AI brain behind Copilot Studio’s conversational agents. When a user sends a message, the orchestrator evaluates the input and decides what to do next. It might answer directly from a configured knowledge source (RAG), redirect the user into a static dialog topic, or invoke a tool like a Power Automate flow, a connector, or MCP server tool. It’s a powerful routing mechanism – when it works.

The problem is what happens to conversational context as the orchestrator makes those decisions.

The Memory Loss in Action

Here’s a reproducible scenario that illustrates the issue perfectly (using the default ChatGPT 4.1 model).

You start a conversation with your copilot and say: “My nickname is Mittens.” The orchestrator responds with something like “Nice to meet you, Mittens!” — so far, so good. The orchestrator owns the conversation, is retaining some information, and responding naturally, without having to do any retrieval, redirections to topics, or invoking any Tools or Connectors.

You then say “My favorite team is the Seahawks.” Again, it acknowledges this and stores it in its working context.

Now ask it something it has to think on, like “What is today?“. No problem, it answers fine.

At this point, if you were to ask it to recall your nickname, or favorite team, it should have no problem re-stating those items. But let’s not ask it to recall just yet.

Now give it a larger request, one that fills up the context window a bit, such as “Generate 500 words of lorem ipsum text.“.

Now that the context window has been stuffed, ask it to recall your favorite team. “What is my favorite team?“

Failure. “I could not find any information about your favorite team.“. Ask it to summarize the conversation so far and it can only recall the most recent exchange for the lorem ipsum text. Everything before that has been silently discarded.

So what happened? It seems that the model generated a response large enough to consume the available context budget, and the earlier conversation turns fell off the edge.

Measuring the Gap

I tested this systematically with the ChatGPT 4.1 model, which has a 32,000-token context window, in a couple of different tenants. ChatGPT 4.1 in some regions and via the API can even have a window of up to 1 million tokens, and you would think that this is what Microsoft would be using and hosting it in Azure OpenAI service.

I established facts at the start of a conversation, then asked the copilot to generate progressively larger blocks of lorem ipsum text before checking recall. I could get it to fail consistently between 500-800 words of extra filler text, plus my initial testing facts at the beginning.

When changing the model to ChatGPT 5 (chat), the context window expanded considerably. Still, context was reliably lost after approximately 6,000 words of generated filler text – roughly 8,000 tokens.

That’s only about 25% of ChatGPT 5’s advertised 32k context window. The other 75% is being consumed by something else before your conversation history even gets a seat at the table.

I have no idea why GPT-4.1 model is significantly worse, and unfortunately for sovereign cloud clients like GCC, it is currently the only model option available.

So what’s eating the rest of the window? On every turn, the model’s context has to accommodate the copilot’s system instructions, descriptions for every configured topic, descriptions for every action and plugin, knowledge source configuration and metadata, and the orchestrator’s own internal planning prompts and scaffolding. That overhead is substantial, and it’s invisible to you as a builder. Microsoft provides no tooling to inspect how much of your context window is allocated to conversation history versus platform overhead, and no documentation on what that split looks like.

The model’s advertised context window is not what you’re getting. The effective conversation history budget in Copilot Studio appears to be in the single-digit hundreds (ChatGPT 4.1) or thousands (ChatGPT5) of tokens, regardless of what the underlying model supports. And there’s no way to see, measure, or control this from within the platform.

Is This a Cost Optimization?

It’s worth asking why the gap is so large. The orchestrator’s overhead – instructions, topic descriptions, action metadata — shouldn’t consume 75% of a 32k token window. Even a copilot with dozens of topics and actions would struggle to fill 24,000 tokens with descriptions alone.

One plausible explanation is that Microsoft is artificially constraining the conversation history window as a cost optimization. Longer context windows mean more tokens processed per API call, which means higher compute costs per turn. By limiting how much conversation history is carried forward, Microsoft reduces the per-turn cost of running the orchestrator – at the expense of conversational continuity.

If that’s what’s happening, it’s a reasonable business decision. But it should be a transparent one. Builders need to know what they’re working with so they can design accordingly, rather than discovering through trial and error that their copilot can’t remember a user’s name from five turns ago.

A Workaround That Proves the Point

The good news is that you can build a workaround. The bad news is that it requires reimplementing conversation memory from scratch – and the fact that it works actually proves something is being left on the table.

The approach involves maintaining a rolling conversation summary in a global variable and injecting it back into the orchestrator’s instructions on every turn.

Building the Transcript

Copilot Studio doesn’t expose the orchestrator’s internal conversation history to topic flows. There’s no System.ConversationHistory variable, and the Generative Answers node runs in its own isolated LLM session with no access to what the orchestrator has been tracking. So you have to build the transcript yourself, turn by turn.

To do this, first initialize a global variable in the Conversation Start system topic, called ConversationHistory. You can set it’s initial value to Blank().

Create a new custom topic, called StoreInputHistory, and change the trigger to “A message is received“.

Add a Set variable value node after the trigger. Choose the Global.ConversationHistory variable to set, and use the following PowerFx formula:

Concatenate(Global.ConversationHistory, " | ", "User: ", System.Activity.Text)

To capture the bot’s responses, create another custom topic called StoreOutputHistory, and change the trigger to “An AI generated response is about to be sent“. Also use the Global.ConversationHistory variable, and the following PowerFx formula:

Concatenate(Global.ConversationHistory, ” | “, “Bot: “, System.Response.FormattedText)

Injecting the Summary

The copilot’s Instructions field is evaluated fresh on every turn with current variable values. In the Instructions editor, add text like: “The following is a rolling summary of this conversation. Use it to maintain continuity and remember facts the user has shared.” Then type / to bring up the variable picker and select your Global.ConversationHistory variable.

The orchestrator now sees the summary in its instructions on every turn. Even when the raw conversation history gets truncated, the key facts survive.

Why This Proves Something Is Wrong

Here’s the thing: this workaround works. After implementing the rolling summary, the orchestrator retains context across long conversations, through topic transitions, through knowledge retrievals, through large responses. The memory problem goes away.

But the summary is being injected into the Instructions – the same instructions that are part of the orchestrator’s overhead. If 75% of the context window were truly needed for the orchestrator’s internal scaffolding, adding a summary variable to the instructions should make things worse by consuming even more of that overhead budget. Instead, it fixes the problem.

This suggests that the conversation history is being truncated more aggressively than the overhead requires. There’s headroom in the context window that isn’t being allocated to conversation history, and a short summary variable is enough to fill the gap. That’s consistent with an artificial constraint on how much history gets carried forward – not a genuine space limitation.

What Builders Need from Microsoft

Copilot Studio is a powerful platform. The generative orchestrator’s ability to blend AI reasoning with structured topics and plugin actions is genuinely impressive. But that power is undermined when the orchestrator can’t maintain basic conversational continuity, and builders have no visibility into why.

What we need is transparency. Publish the effective conversation history budget for each model tier. Expose a system variable with the orchestrator’s conversation transcript. Give builders a configuration option to control the history-to-overhead ratio, even if it comes with cost implications. And if the constraint is a cost optimization, say so – let builders make an informed decision about the trade-off between cost and conversational quality.

Users expect that if they tell a bot their nickname at the beginning of a conversation, it still knows that nickname five minutes later. That’s not a power-user expectation – it’s the bare minimum. The frustrating thing is that this feels like a problem Copilot Studio should solve out of the box, without workarounds like the one above.

Until then, if you’re building anything beyond a simple Q&A bot in Copilot Studio, plan and test for memory management from day one. Your users will thank you — assuming your copilot can remember who they are.

The post Copilot Studio’s Generative Orchestrator Has a Memory Problem first appeared on Life on Planet Groove - Adam Toth's Blog.

Dataverse for Teams is a subset of standalone Dataverse in the Power Platform, and while it has many of the main characteristics of Dataverse, there are some features that are scaled back or simplified, especially with regards to advanced security configurations. The inability to create custom Security Roles, no Record Sharing capability, and the simplified permission sets available (Full Control, Collaborate, Reference, Private, None) make it harder to create custom roles and permission levels that don’t directly correspond to the Owners/Members/Guests hierarchy. For example, maybe you want to expose table data to your external partners who you invite to your Teams as external Guest users, and you want each partner organization to view their own organization’s records but not see or edit records from other organizations. The simplified permissions in Dataverse for Teams make it difficult to achieve this, as all the users will be treated as “Guests” collectively and assigned the same permission levels that all Guests are assigned to the tables, and you don’t have a mechanism to further group these users beyond Owners/Members/Guests. This post will show you a creative way to achieve this using record ownership instead of custom security roles.

The quick summary – you can create custom “Teams” in Dataverse for Teams (just like in standalone), and assign record ownership to a Team instead of an individual user, and thereby create another hierarchical layer of permissions. Read on to understand the backstory more, or jump ahead to see how to do it.

Overview of Dataverse Security and Permissions

Before getting started, take some time to review the official documentation for how security works in Dataverse, I’ve highlighted some key links below:

• Security in Microsoft Dataverse
• Security Concepts in Microsoft Dataverse
• Security Roles and Privileges
• Compare Dataverse and Dataverse for Teams

At the core of standalone Dataverse is a hierarchical role-based permissioning system where you can define named Roles, assign users to those Roles, and then assign specific permissions to Dataverse resources (Tables, Rows in those Tables, and even Columns) to those Roles. These objects are actually stored in Dataverse tables, with many to many relationships between these objects. A crude representation of this is below:

• [Users] <-> [Security Roles] <-> [Privileges] <-> [Resource]

There is even a concept of a grouping mechanism, to which you can assign users, and then assign that group to the Security Role. This custom group is called a “Team” in Dataverse, and lives in a table called “Teams”. So we can update the mapping above to show that you can either assign users directly to roles, or assign them to a Team, and then assign the Team to a role:

• [Users] <-> [Security Roles] <-> [Privileges] <-> [Resource]
• [Users] <-> [Teams] <-> [Security Roles] <-> [Privileges] <-> [Resource]

If you are familiar with SharePoint and SharePoint permissions, this ad-hoc group is very similar to a SharePoint Group. You can create these groups (Teams) yourself, and you can either add users individually to them, or link them to Azure AD Security Groups or M365 Groups (these are called “Group Teams“).

Here is where it gets confusing, and where the nomenclature is going to bite me, so I’ll try and lay out the terminology I’ll use for the rest of this post to hopefully avoid confusion.

“Microsoft Teams” Team – This is a Team created in the Microsoft Teams client, that is used for collaboration. It has Owners, Members, and Guests roles, and has channels and tabs for chat and access to Teams related apps.

“Dataverse” Team – This is a record inside of a Dataverse database table called “Teams”. This record represents a custom or built-in group that you can leverage for permissions. Official doc links for this:

• Teams (and Group Teams)
• Microsoft Dataverse Teams Management

Dataverse for Teams (DVFT) – A dedicated Power Platform environment and Dataverse database for a specific “Microsoft Teams” Team, in which you can store data, Power Apps, Power Automate workflows, and Power Virtual Agent chatbots. This environment/database is linked to it’s “Microsoft Teams” Team lifecycle – it is created when the first Power Platform asset is created within the “Microsoft Teams” Team, and deleted when the linked “Microsoft Teams” Team is deleted.

The Problem

If you look at the detailed comparison on security between Dataverse for Teams (DVFT) and standalone Dataverse, you’ll see a number of differences, most importantly:

• No Record Sharing
• No hierarchical security
• Cannot create custom User Roles, and are limited to the default Teams Owners/Members/Guests roles (we call this the OMG pattern)
• Are limited to just one Business Unit (means you can’t create an organizational hierarchy structure for permissioning)

These differences, combined with a limited set of privilege levels makes it very hard to create customized roles and groups within your DVFT applications for more advanced security implementations.

The default privilege levels in DVFT are as follows:

• Full access – Allows end users to see and edit all records in the table.
• Collaborate – Allows end users to see all records, but they can only edit their own records.
• Reference – Provides a read-only view of data for end users.
• Private ­– Allows end users to only view and edit their own data.

What a lot of my customers are looking for is a way to create custom groups of users within DVFT, assign users to those groups, and let anyone in a particular group see just the records for that group, and not other groups. With the privilege levels above, Collaborate, Reference, and Private would not work because those would either give read access to all records, or give Read/Edit access to only records directly owned (created) by the individual user.

To accomplish these requirements, it would seem that we need to give all guest users Full Access permissions, and just filter what they see and access in the UI using Filter() formulas and PowerFx logic. But this is certainly error-prone, and if a developer in the future forgets to filter some data properly, then data could be leaked across organizations/roles.

What we need is a way to create custom groups and have the group own the record, so that true security trimming is in place, not just filtering. This is where custom “Dataverse” Teams and record ownership come in.

The Solution – Custom “Dataverse” Teams and Record Ownership

Now, for what I am going to show you next, there is no pre-built, pretty user interface for managing “Dataverse” Teams and changing record ownership, but the capabilities are all there to do this from Power Apps or Power Automate workflows that you build in DVFT.

To start with, I’m going to walk through how to create a custom “Dataverse” Team. Since these are stored in a table called Teams, I’m just going to create a new Power App in DVFT, and add the Teams table as a Data Source (Start this screen… with data).

Here I am creating a new app and naming it:

When the app loads up, I’ll choose the first option to Start this screen … With data:

When asked to Select a data source, I’ll type Teams in the search box and choose the Teams table:

Once the screen is created, you’ll see that you are browsing the records in the Teams table directly. One potentially confusing thing is your Datasource will get named “Teams_1” in the app. This is so that it doesn’t collide with the Teams Integration control that is added to every DVFT Power App which is already named “Teams”. In Power Apps every control needs a unique name.

On the newly created screen you’ll see a few default teams in the gallery there. The one that is named the same as your “Microsoft Teams” Team is for Collegues with Access when you share your Power App with other collegues. The Team with the orgXYZ prefix is the single Business Unit you are allocated in DVFT (you aren’t allowed to create additional business units). And you’ll also see Teams Owners, Teams Members, and Teams Guests. These last 3 are “Group Teams”, linked to the Azure AD M365 group that backs your “Microsoft Teams” Team.

To see some more details about the groups, I will edit the EditForm control to show a few additional fields about the selected Team, including “Team Type” and “Membership Type”:

Now that I’ve added those fields, we can see the Team Type is AAD Office Group, and the Membership Type is one of either Owners, Members, Guests, or Members and Guests.

To create a custom team, the only required fields are these three – Team Name, Team Type, and Membership Type. I’ll just use the New record button to create a new team called Contoso, and another called Fabrikam. For Team Type, you need to choose “Owner”, and for Membership Type I am going to choose “Members and Guests” (no matter what you set it to, the only option that will save is “Members and Guests”). You can see my newly created “Dataverse” Teams below:

Now that I have some Teams created, I am going to assign users from the Users table to the Team. This can easily be done using the Relate/Unrelate Power Apps functions (or the Relate/Unrelate a Record actions in Power Automate). Users to Teams table relationship is Many-To-Many, so you can’t use Patch or EditForm to set this. To accomplish this, I am going to add a gallery underneath the current EditForm control to display related Users to the selected Team, and then a ComboBox and Button to select users and Relate them to the team. I’ll also add a Delete button on the gallery to Unrelate. The Items property of the new gallery will just traverse the relationship from the selected Team in the main left gallery:

BrowseGallery1.Selected.Users

For the ComboBox, I am going to set the Items property to the Users table in Dataverse, and Allow Searching:

For the button, I’ll use the following formula for OnSelect:

Relate(BrowseGallery1.Selected.Users, ComboBox2.Selected)

And lastly, for the delete button in the gallery, I’ll use the following formula to Unrelate the record:

Select(Parent);Unrelate(BrowseGallery1.Selected.Users,ThisItem)

You can see in the picture below the user that has been related to the selected Contoso team:

You can make this UI more advanced and user friendly, but for now I’m keeping it simple to demonstrate the concept.

Now that I’ve created a custom Team and assigned a user to it, there is one final thing that needs to be done before changing record ownership to the Team. In order to assign a “Dataverse” Team as the owner of a record, it must have Read permissions to the table (it would make no sense to assign an Owner that couldn’t even read the record). Right now, my newly created group does not have any explicit or implicit permissions to any of the tables in Dataverse. To give it access, I will relate the “Dataverse” Team to one of the pre-existing Security Roles, namely “Teams Guest”. Each DVFT environment comes with several pre-existing Security Roles, including “Teams Owner”, “Teams Member”, and “Teams Guest”. When you assign Table permissions within the DVFT UI, you are actually assigning one of these 3 security roles one of the privilege levels to the table. The UI filters out all the other system-generated roles like sysadmin, system customizer, etc. Those roles are there, but you are not allowed to create additional roles or see these other roles in the UI.

To accomplish this, I will create another screen in my application to browse the Security Roles, and a similar Gallery/ComboBox implementation to browse related Teams and relate a team to the role. I’ll choose to create a New Screen > Blank Screen > Start with Data > and choose the Security Roles Table.

For my new gallery Items property I will set it to:

BrowseGallery2.Selected.Teams

And for my ComboBox, the Datasource (Items Property) will be set to “Teams_1” and I will allow searching. For the Add Team button, I will use a similar Relate formula:

Relate(BrowseGallery2.Selected.Teams, ComboBox3.Selected)

Here I am showing the newly related Contoso Team:

Changing Record Ownership

Now that I have a custom Team record in place, a user associated to the Team, and I’ve given the Team a security role, I can now assign records to have the Team as an owner instead of the original Created By user.

If you are unfamiliar with record ownership in Dataverse, every table in Dataverse has a column named Owner. This column can store a reference to either a User or a Team or even a Business Unit. Usually the Owner is set to the original creator of the row (the person listed in the Created By column), but it can be changed, and set to a different user, or also to a “Dataverse” Team.

To set the Owner field in Canvas Apps, you need to use a Patch() formula (see this great article for more details), as the EditForm control locks the Owner field from editing.

UPDATE 11/2/2022: Actually, you don’t have to use the Patch formula, you can also set the Owner field from an EditForm control. Add the field Owner to the EditForm control. It will add an empty DataCard to your form. To update the ownership, set the Update property of the DataCard to the “Dataverse” Team record that you want to be the owner of the record, for example Lookup(Teams_1, ‘Team Name’=”MyTeamName”). In this way, you can change ownership directly to the team at time of record creation (FormMode.New) or during update (FormMode.Edit).

To demonstrate this, I am going to create another blank screen, and this time start from a new table. I’ll create a a table called “Discount Codes“. In this scenario, I am inviting my Resellers to come into my app and create trackable discount codes for use when reselling my products. I only want users to see their own organization’s discount codes, not any others.

I’ll create the custom table “Discount Codes” with two fields, Name (Text), and Expiration Date (Date). I’ll also add the Owner column in the default view so that we can see the values there.

Once done editing the table, back on the canvas app screen I’m also going to change the EditForm control so it displays Owning User, Owning Team, and Owning Business Unit values, just so you can see this.

For now, just to prove that I can indeed change ownership, I am going to place a ComboBox and Button in order to manually change ownership to my Contoso or Fabrikam team I created earlier.

The ComboBox Items will be bound to the Teams_1 data source (Teams Table), and the Button’s OnSelect will look like this:

Patch('Discount Codes', BrowseGallery3.Selected, {Owner:ComboBox4.Selected})

You can see that after I select Contoso from the ComboBox and click the button, that ownership is reset to the Team instead of the individual user (Owning Team is now Contoso, and Owning User is empty):

I’ve gone ahead and assigned one record to Contoso, and the other to Fabrikam.

Now, I’ll move this screen up to the top of the Tree View so it becomes the Start Screen for the application. Before I log on with an external guest account and verify the permissions, I am going to check the Table permissions on my custom Discount Codes table to make sure they are correct. I will save and Publish my app to the General channel in the team first, and then go to the Build tab of the Power Apps App, and open up my table for editing. You can see that on my table, Team Members have Full access, and Guests have Private permissions (which means an external guest should only be able to see and edit their own rows.

Now I will login to the Team as an external user that is a member of the Contoso custom Team I created, and I should only see SpookyFall2022 discount code, which is indeed what I see:

The great part about this is I am now relying on actual security to trim the rows, as opposed to a developer just filtering things via queries. It is now impossible for a user who is associated with one “Dataverse” Team, to see records owned by other Teams (or other Users) as long as ownership is setup properly.

Summary and Closing Thoughts

In this post I’ve shown how you can create custom “Dataverse” Team records, associate users to those teams, and then assign record ownership to the custom teams in order to get advanced layers of security in your Dataverse for Teams apps, instead of granting overly broad permissions and relying on crude filtering for security.

Using this approach, you will still need to manage the process of changing record ownership yourself. Records created will always be assigned ownership to the original user that created the record by default. But you can do this with additional formulas that execute after Patch() or SubmitForm() statements, or you can even automate this by creating a Power Automate workflow triggered when Rows are Added to the table, that does the reassignment automatically. Even if the reassignment fails temporarily, the worst that will happen is the record will only be visible to the creator instead of to the broader members of the custom “Dataverse” Team, so no data will be leaked.

If you like this approach or have comments or questions on it, please leave a comment in the thread below. Thanks for reading!

The post Advanced Security in Dataverse For Teams via Record Ownership first appeared on Life on Planet Groove - Adam Toth's Blog.

Overview

I am continually amazed at the creativity coming from the low-code/no-code space these days, and a post by Matthew Devaney today gave me some inspiration to build on the solution and make a component out of it for easier consumption. In short, Matthew made a slick solution for applying a number formatting mask to a Text Input control as the user types in it.

First of all, you should go read Matthew’s post Power Apps Phone Number Formatting For Any Country (Input Mask) for the underlying concepts and technique for accomplishing the number mask feature. Once you’ve read that post, come back here to see how to turn it into a reusable component. Components make things much more consumable by app authors, and if you want a primer on Components you can read for following links:

• Create a component for canvas apps – Power Apps | Microsoft Docs
• PowerApps Reusable Components – Life on Planet Groove

Creating the Component

To make the input number mask more easily consumable, I am going to show how to make use of PowerApps Components. This will enable app authors to add input mask capabilities multiple times on a single screen or on other screens in an app with a lot less manual configuration, as the bulk of the logic formulas are encapsulated in the Component and don’t need to be constantly copy/pasted every time you need to use it.

My goal is to be able to easily insert a number mask component next to each TextInput that needs to be masked, and then set a few properties on the Component and TextInput to link them together and get the functionality. No cut/copy/paste of any complex formulas necessary.

To start with, I am going to create a new Component by clicking the Components tab in the left tree view area, and choosing + New Component.

I’ll name the Component “InputNumberMask”. I’ll set the default Width to something relatively small like 135, and height to 35.

Next, I’ll Insert a Label and a Slider. I’ll set their X and Y positions both to 0, and their Width and Height properties to Parent.Width and Parent.Height.

Adding Custom Properties

Next, I’ll add some input and output properties to my control, which will be used to set the desired number mask and supply the input text to mask, and will return the output masked text and a max length number.

First I’ll add an input property of Type Text called “NumberMask”. This will be the desired mask format that a user will configure. A key option when setting this property up is to check the box to Raise OnReset when value changes (you’ll see why in a moment).

Next I’ll add an input property of Type Text called “TextToMask”. This will be the text that is typed into the TextInput that needs to have the mask applied to it.

Next, I’ll add another property of type Behavior. These are new and still in Preview/Experimental phase, but they enable creating behavior/event properties like OnChange, OnSelect, etc. To enable this, I’ll have to go to the File menu, choose Settings, Upcoming Features, and under Experimental enable the Enhanced Component Properties feature.

With components, in general you can’t reference controls directly between components and screens, you can only pass input/output variables I’ll need some way of calling Reset() to reset the value in my TextInput, and since I can’t pass in a Control as an input parameter, I’ll instead raise a custom event from within the component. I’ll add this last property as a Behavior type, call it OnChange, and set the Type to Boolean.

Finally I’ll add two output properties. The first one will be named “FormattedText”, be type Text, and will contain the final text value with mask applied.

And the last property is a convenience one, “MaxLength”, type Number, which will just be the total Length of the FormattedText, so you can set the MaxLength of your TextInput equal to this.

Configuring the Slider and Component with Masking Formulas

Now that the properties are configured, I can port over Matthew’s formulas into the Slider control and Component properties. I’ll select the Slider control, and set the Default property of the Slider equal to Len(Parent.TextToMask).

In the OnChange of the Slider, I’ll use Matthew’s code as is, except I’ll change the MatchAll function to grab from Parent.TextToMask property instead of directly from the TextInput:

Set(
    varFormattedNumber,
    With(
        {
            varTextNumbersOnly: Concat(
                MatchAll(
                    Parent.TextToMask,
                    Match.Digit
                ),
                FullMatch
            )
        },
        Text(
            Value(varTextNumbersOnly),
            LookUp(
                colNumberFormat,
                CountNumbers = Len(varTextNumbersOnly),
                NumberFormat
            )
        )
    )
);
Parent.OnChange()

Note with the code above, we are creating/updating a variable, varFormattedNumber, to store the output masked text every time the Slider changes (which is every keypress of the TextInput). Also note the added line at the bottom to raise the component’s custom OnChange event.

Next, I’ll select the Component itself. In the OnReset property, I’ll paste the other big block of Matthew’s that is responsible for creating the Collection of mask characters. Again, minimal changes are needed, and I’ll just grab the mask from the Component’s property directly (Self.NumberMask):

ClearCollect(
    colNumberFormat,
    With(
        {varTextNumberFormat: Self.NumberMask},
        With(
            {
                varTableNumberFormat: ForAll(
                    Sequence(Len(varTextNumberFormat)),
                    With(
                        {
                            varNumberCurrentLength: Left(
                                varTextNumberFormat,
                                Value
                            )
                        },
                        {
                            NumberFormat: varNumberCurrentLength,
                            CountNumbers: CountRows(
                                MatchAll(
                                    varNumberCurrentLength,
                                    "#"
                                )
                            )
                        }
                    )
                )
            },
            ForAll(
                Sequence(
                    Max(
                        varTableNumberFormat,
                        CountNumbers
                    )
                ),
                LookUp(
                    varTableNumberFormat,
                    CountNumbers = Value
                )
            )
        )
    )
)

Note that this OnReset event will be triggered every time a consumer of the component sets or changes the NumberMask property (which is why it was important earlier to Raise the OnReset event for this property). The component needs some event to fire in order to create the collection/table of mask characters, and the OnReset of the control is a perfect place to do that.

Next, I’ll change the MaxLength property on the component so that it defaults to Len(Self.NumberMask).

Then I’ll change the FormattedText output property to varFormattedNumber.

Finally, I’ll set the Slider Visible property to False, and set my Label’s Text property to Parent.NumberMask. This last part is just so that at design time a developer can see this component visually initially. After configuration, the consumer can set the Visible property of the Component itself to False so nothing actually shows in the UI.

Consuming the Component

To use the Component, I’ll go back to the Screen tab on the Treeview, and I’ll Insert a TextInput control on my canvas, and then also insert an instance of my InputNumberMask component right next to the TextInput.

To wire these two up together, I’ll select the Component and set the NumberMask property to whatever mask format I want, for example for US phone numbers it would be “(###) ###-####” or for US social security numbers “###-##-####”. Another cool idea is to set this mask string as the HintText property on your TextInput control, and then point the NumberMask property on the component to the HintText (TextInput1.HintText). This way your users will see a little placeholder in the TextInput with what the mask will look like.

For the TextToMask property, I’ll set it equal to the .Text property of my TextInput (in this case it is TextInput1.Text).

Lastly, I’ll set the OnChange property of the component to Reset(TextInput1).

Now I’ll set a couple properties on the TextInput itself. First, I’ll change its Default property to my Component’s output property, FormattedText (InputNumberMask_1.FormattedText).

And finally an optional property if you want to enforce MaxLength, is to set the MaxLength of the TextInput to the Component’s MaxLength output property (InputNumberMask_1.MaxLength).

I can play/preview the App and see it in action:

Conclusion and Download

By creating this as a Component, I’ve encapsulated all the logic in one place, and to consume it, I just need to add the Component to the screen and set 5 properties (3 on the component, and 2 on the TextInput). I can easily add multiple instances of this component on a screen (to support multiple TextInputs).

I’ve uploaded an exported zip of my sample app with the component in it standalone, and also as a component library in a Solution package. Feel free to use in your apps or build upon it.

The post PowerApps TextInput Number Mask Component first appeared on Life on Planet Groove - Adam Toth's Blog.

6. Armored Leadership
Hiding Behind Cynicism

Cynicism and sarcasm are first cousins who hang out in the cheap seats. But don’t underestimate them – they often leave a trail of hurt feelings, anger, confusion, and resentment in their wake. I’ve seen them bring down relationships, teams, and cultures when modeled by people at the highest levels and/or left unchecked. Like most hurtful comments and passive-aggresiveness, cynicism and sarcasm are bad in person and even worse when they travel through email or text. And, in global teams, culture and language differences make them toxic…

In a world roiled by incessant and tumultuous change, swamped by boatloads of fear and anxiety and rampant feelings of scarcity, cynicism and sarcasm are easy and cheap. In fact, I’d say that they’re worse than armor – we use cynicism and sarcasm as getting-out-of-contributing-free cards.

First of all, the author is conflating sarcasm, skepticism, and pessimism with cynicism, while these all have very different meanings behind them. For example, later on, she writes:

Cynicism and sarcasm often mask anger, fear, or feelings of inadequacy, and even despair. They’re a safe way for us to send out an emotional trial balloon and if it doesn’t go over well, we make it a joke…

And later this:

Again, while a cynic might argue that someone who clings to hope is a sucker, or ridiculously earnest, this type of armor typically comes from pain. Often, people’s cynicism is related to despair. As the theologian Rob Bell explains, ‘Despair is the belief that tomorrow will be just like today.’

This is pessimism, for sure, and potentially skepticism (doubt in the face of truths that show tomorrow will be different), but this is not cynicism.

Understanding Cynicism and its Roots

Cynicism is an ancient Greek philosophical school of thought. The ancient Cynics aimed to live in harmony with nature, and to eschew wealth, fame, fortune, and power, often via ascetic practices. Ancients Cynics would often point out the hypocrisy of others, exposing their motives and pretensions underlying the norms of society. Their goal was to achieve happiness through virtue.

There is nothing in ancient cynicism around despair, hopelessness, pessimism, inaction. Rather there is the challenging of norms and conventions, and the questioning of motivations of others, and whether they are acting solely out of self-interest, or out of virtue. Reading about the prototypical Cynic, Diogenes, one can see the true roots of this school of thought.

In modern or contemporary meanings, cynicism has evolved to mean a questioning or distrust of the motives of others. A line from Wikipedia stands out to me:

Cynicism is often confused with pessimism or nihilism, perhaps due to its distrust in others. The differences between the three is that cynicism is a distrust by prudence; while due to a sense of defeatism, pessimism is the distrust of potential success. Nihilism on its part have distrust cast upon the belief that life have any valuable meaning.

Wikipedia: Cynicism (contemporary) – Wikipedia

I think in the case of Dare to Lead, cynicism is being miscast as pessimism, and while I can certainly agree that pessimism is an undesirable quality in an organization, along with sarcasm, I do think that cynicism has an important role to play as a check and balance against corruption.

Cynicism is a tool that can point out injustices, inequity, and expose selfish motivations behind decisions in our workplaces. It is cynicism that enables us to ask “why is my company’s Political Action Committee donating money to senators and congress people who actively supported insurrection against our country?”, or to question the motivations behind the differing response of force at the Jan 6th insurrection, vs the BLM protests in the same area, or whether this licensing change is actually a bait and switch for our customers and will really tick them off.

In fact, our constitutional democracy is based heavily on a Madisonian cynical view that assumes that people in government are motivated by self-interest, and that earlier democracies had been failures for not taking this into account.

But it is wrong to assume that cynicism has no place in a well-ordered constitutional system. In fact, the opposite is true. Cynicism about governmental abuse of power as well as the tendency of interest groups to influence and control government inspired the Framers. In fact, a dominant theme of The Federalist Papers is “the desirability of adopting the Constitution as a means of controlling interest groups.” In The Federalist No. 10, James Madison “expressly embraced the notion that what would separate his constitution from those that had gone before it would be a more realistic [i.e., cynical] conception of human nature.”‘ As I previously observed: The problem confronting the Framers was that, on the one hand, they did not want to organize another monarchy, but on the other hand, the earlier democracies had all been abject failures, nothing less than ‘spectacles of turbulence and contention.’ Madison’s view was that the problem with previous democracies had lain in the assumptions made by their organizers. Specifically, prior to the Federalists’ construction of our political regime, ‘the whole of political thought had turned on ways to inculcate virtue in a small class that would govern.’ In stark contrast, the government that Madison had in mind (and the one that ultimately emerged) would be based on the [cynical] assumption that the postconstitutional world would be populated by people motivated by self-interest rather than by virtue. The Framers frankly and self-consciously took the view that they had to construct the Constitution to deal with the corruption and ineptitude of the leaders who would govern the postconstitutional order.

Jonathan R. Macey, Cynicism and Trust in Politics and Constitutional Theory, 87 Cornell L. Rev. 280 (2002) Available at: http://scholarship.law.cornell.edu/clr/vol87/iss2/2

I would argue that in discouraging cynicism, and not listening to the issues raised by the questioning of motives and intentions can actually be one of the root causes of anger and resentment in the organization, and a barrier to real effective change. Trust is necessary in any organization, but so is a healthy dose of cynicism to keep any corruption in check.

This book, Dare to Lead, is about the qualities necessary to be a brave, empathetic, and effective leader, through listening, having tough conversations (“rumbles” as they are referred to in the book), “being vulnerable”, and “living into our values”. And so I question why this same book is discouraging cynicism, which is one of the tools that employees have at their disposal to speak truth to power. It’s very easy to avoid hard conversations as a leader when you discourage the people underneath you from questioning and challenging your motivations that drive your decision-making.

I was honestly enjoying the setup to this section of the book, which included having “hard conversations”, embracing vulnerability, building a “Safe container” so that employees can share difficult or challenging things without fear, and yet I come to this part of the book and am essentially told that no, it’s not ok to have a questioning attitude. If we can’t question motives, then we are all just essentially “yes-people” in the org.

This immediate dismissal of cynicism has the Cynic in me now fully awake, and questioning the motives of leadership for even assigning me this training. Is it to create a culture of “yes-people”? I know this is most likely due to the author not really taking the time to understand cynicism, and conflating it with other behaviors, but I would expect the author to understand the difference, and to recognize the unique meaning of cynicism and its necessity in an organization.

I for one feel that we need a little more cynicism in the workplace, and I would hope that my leadership would exercise cynicism and question the motives of their leaders, so that we have accountability all the way to the top.

The post On the Value of Cynicism in the Enterprise first appeared on Life on Planet Groove - Adam Toth's Blog.

Overview

Power Automate’s default response to errors from connectors is pretty simple – exit the workflow right there, and record the entire run as a failure. In most cases this is what you might want, however sometimes you need to handle an error yourself and take action on it, or ignore it and move on, similar to a try-catch approach in many programming languages.

For example, before committing a record, you might want to check if it already exists first. If it does, then perform an update, if it doesn’t, go ahead and create it. When calling a RESTful web service to fetch a record by a unique ID, if it can’t be found, the service will most likely return a 404 status code. In Flow, a 404 is considered an error, and the workflow will fail and terminate at that point unless additional error handling is implemented. In this case though, a 404 shouldn’t be considered an error per se – it’s a legitimate response that tells you something, which you want to then handle and move on from.

To handle an error in Flow, you have to first configure the Run After behavior of your action that you want to happen after the error. You can configure the Run After behavior by clicking the ellipsis (…) on the title bar of an Action, and choosing Configure run after.

The default setting for every action is to only run if the previous action was successful. If the previous action generates an error, then the workflow will exit before executing the subsequent action. To handle an error then, you will need to make the subsequent action run even if the previous action failed, which you can enable with the “has failed” checkbox.

In the image above, I have a SharePoint GetItem action followed by a Switch action, and the Switch is set to run if the SharePoint action fails or is successful.

Handling Status Codes

The great thing about the Connectors in the Power Platform is that they are built on web service standards. Each connector is basically a wrapper around a first party or third party web service, and leverages HTTP requests under the hood to communicate. Since each request through a connector is just a web service call, then we should be able to get at the status code response, the headers that the server sent back, and the body of the response.

Power Automate exposes all of this to us via Expressions, which are built using the Azure Logic Apps Workflow Definition Language. Using the outputs() function in an Expression, we are able to get at the complete HTTP response from a connector action. Check out the nice docs for this function, where you can see a sample JSON response from a Twitter GetUser action:

{
  "statusCode": 200,
  "headers": {
    "Pragma": "no-cache",
    "Vary": "Accept-Encoding",
    "x-ms-request-id": "a916ec8f52211265d98159adde2efe0b",
    "X-Content-Type-Options": "nosniff",
    "Timing-Allow-Origin": "*",
    "Cache-Control": "no-cache",
    "Date": "Mon, 09 Apr 2018 18:47:12 GMT",
    "Set-Cookie": "ARRAffinity=b9400932367ab5e3b6802e3d6158afffb12fcde8666715f5a5fbd4142d0f0b7d;Path=/;HttpOnly;Domain=twitter-wus.azconn-wus.p.azurewebsites.net",
    "X-AspNet-Version": "4.0.30319",
    "X-Powered-By": "ASP.NET",
    "Content-Type": "application/json; charset=utf-8",
    "Expires": "-1",
    "Content-Length": "339"
  },
  "body": {
    "FullName": "Contoso Corporation",
    "Location": "Generic Town, USA",
    "Id": 283541717,
    "UserName": "ContosoInc",
    "FollowersCount": 172,
    "Description": "Leading the way in transforming the digital workplace.",
    "StatusesCount": 93,
    "FriendsCount": 126,
    "FavouritesCount": 46,
    "ProfileImageUrl": "https://pbs.twimg.com/profile_images/908820389907722240/gG9zaHcd_400x400.jpg"
  }
}

Notice the collection of headers we have access to, the body of the response, and the statusCode.

Using this, we can write Conditions that check the return status code and handle errors accordingly. The syntax for getting the HTTP Status Code in an Expression is like this:

outputs('your_action_name').statusCode

Note that your action name needs to be in single quotes (not double!), and if you have spaces in your Action name (which most do), you’ll have to escape them with underscores instead.

A really nice pattern for error handling is to use a Switch action, and use the above formula in the “On” field. Click in this field, and click the Expression tab. Type this formula and click the OK button to insert your expression.

Then you can create a Case for each expected status code. For example,  Case ‘200’, you can then Update the item, Case ‘404’ create a new item, and Case ‘500’ terminate the workflow with an error message (because something unrecoverably bad probably happened).

Below you can see an image of a Flow where I am looking for a specific item by ID from SharePoint, and a Switch that runs if that action succeeds or fails, and then processes 200, 404, and anything else in separate cases:

And here you can see it running with a 404 failure code (I looked for an item with ID 256, which does not exist), and see how it ran the 404 case in the Switch:

Handling Throttling Responses

When you get throttled by a web service, it will usually return a 429 status code. These are handled already by Power Automate, so you don’t have to handle it yourself with home grown looping retry logic. Power Automate already has built-in mechanisms to handle throttling, including automatic retries and exponential back-offs.

You can configure the throttle response behavior by clicking the Ellipsis (…) on the Action title bar, and choosing Settings.

Near the bottom of the page, you’ll find the settings for Retry Policy. The default is an Exponential retry with 4 attempts with 2 attempts (EDIT:11/19/2019, just announced the day I posted this article, this has been changed from 4 to 2, https://flow.microsoft.com/en-us/blog/october-updates-for-microsoft-flow/). You can configure total # of retries, back-off approach (fixed or exponential), and intervals. Notice that 429 (too many requests), 408 (request timeout), and 5XX (internal server error) errors are handled in this way for you.

The post Advanced Error Handling with Power Automate first appeared on Life on Planet Groove - Adam Toth's Blog.

Overview

In this post, I’ll show you how to create reusable canvas components for your PowerApps. If you haven’t seen the announcement and intro videos for this feature, I suggest you check those out here first:

https://powerapps.microsoft.com/en-us/blog/components-available-in-preview/

For this example, I’m going to create a control to display today’s date, visualized as one of those daily tear-off calendars you might have seen at some point on someone’s desk.

Since the component will be reusable on multiple screens, I’ll add properties to the control to set the data and visual configurations. I’ll also show how to use relative sizing to scale the controls when the component is resized, and how to scale font sizes as well.

Creating the App

For this post, I’ll create a new blank Canvas app, using the Phone layout. I’ll name the app CalendarComponent (from File > App Settings), and then Save it (always name and Save your app right away to avoid losing work if your browser closes).

Enabling Components

Components are an experimental/preview feature right now (March 2019), and in order to work with them, you first have to enable that feature. You can do this by going into your app, and navigating to File > App Settings > Advanced Settings. At the bottom of this screen, you’ll see the option to enable Components:

Once enabled, you should see a Components menu item on the Insert menu:

Building the Component

From the Components menu, I’ll select New Component. I will rename it to DailyTearOff.

The first thing I will do is set the component width and height. Your component can be resized once it’s placed on a screen, but this size will be its initial default size. I’ll make this 200×200 pixels:

Next, I’ll add some controls to the canvas.

• A rectangle, 200×45, placed at the top. A label on top of this also 200×45, with font size 21 and Align.Center, Color.White, and Font of Lato Black.
• A label for the date number, 200×120, font size 64, Align.Center, and font of Lato Black. Place this directly underneath the previous two controls.
• Finally another label and rectangle at the bottom, similar to the top, 200×35, font size 16, Align.Center, Color.White, and Font Lato Black.

It should look like this so far (the text in the labels is just static text I typed):

Here is what the initial control tree looks like (I’ve renamed the controls to work with them more easily later):

Adding Properties

A component can have properties, just like other out-of-box PowerApps controls. I’ll add some properties to control the data and display of the component. The first property I’ll add is a Date property. I’ll name it Date, and set the data type to Date and Time, and click Create:

If I click the component in the tree view, and look at it’s properties, I will now see Date. Also notice that it is set to a default value of Now(). I could change that default if I want, and it will also get overridden with whatever the user of the component sets as the value.

Next, I’ll add some properties to control the display of the date info. For example, Month display could use long month, or short month format. Same with the weekday. I could also control casing of the month and day values if I wanted to with additional properties (I’ll leave those as another exercise for the reader).

I’ll add the following additional properties:

• UseShortDayFormat – Boolean, Input
• UseShortMonthFormat – Boolean, Input

Wire the Component to the Properties

Now that the properties are defined, I’ll wire up the component to the values. First, I’ll wire up the Date property so it controls the label values. I’ll start with the day number label. In the Text formula, I’ll put the following:

Day(Parent.Date)

In this case, Parent is the Component itself, so we can reference it that way.

Next I’ll adjust the month and day of week label displays. To get the names of the weekday and month, I’ll use the Text function, with a custom date format string. I’ll also use the boolean properties to control short/long display, and then force upper case. In the day of week label, I’ll put the following:

Upper(If(Parent.UseShortDayFormat, Text(Parent.Date,"ddd"), Text(Parent.Date, "dddd")))

In the month label, I’ll use the following:

Upper(If(Parent.UseShortMonthFormat, Text(Parent.Date,"mmm"), Text(Parent.Date, "mmmm")))

Testing it Out

Now that I’ve got it wired up, I’ll test it out. I’ll switch to one of my screens, and place the component on the screen. It looks nice!

However if I resize the component, not so much:

Relative Positioning

In order to get this to resize well, I’ll have to use relative positioning, adjusting the width/height as well as X/Y positions of the elements, relative to the parent component size. There are lots of ways to do this depending on your requirements, and how I approach this below is just one way of doing this.

For my approach, I’m not going to be concerned about growth in Width so much, but rather when the height changes, I want to adjust the elements inside and scale them. So for all of the controls inside, I’ll change all their Widths to match the component’s, using Parent.Width. To speed this up, I’ll use Ctrl + A to select all the controls on the component canvas, pull down the Width property from the formula bar, and put in Parent.Width.

For the height, I’ll need to know the ratio of the items in their original default sizes (200×45, 200×120, 200×35). Then I’ll adjust the height of each control to be the height of the parent multiplied by this original ratio (CurrentParentHeight * OriginalControlHeight/OriginalControlWidth).

For example, for the top rectangle, I’ll set its height to the following:

Parent.Height*45/200

I’ll go through and do this same thing for each of the controls on the screen.

Finally, I will need to adjust the Y position of each control, so that each control is positioned correctly during resizing. The top label and rectangle will always be at the top, so they will be fixed at Y=0. For the ones underneath, I’ll use relative Y positioning. For the main day number label, I’ll set the Y value to this formula:

RectangleHeader.Height

For the bottom ones, I’ll set it to the following:

LabelDate.Y + LabelDate.Height

At this point, it works much better, with the exception of font-scaling.

At large/wide or small/skinny sizes, it would be nice if the font also scaled as well. Let’s see how we can accomplish that. Fonts are specified in points in PowerApps, and we can convert to pixels with this formula: 1pt = 1.3333333 pixels

If we know the ratio of pixel size to the overall height of each label control, we can adjust the font accordingly. The formula I’ll use is the following:

OriginalFontSize * (CurrentLabelHeight/OriginalFontSize*1.33) * (OriginalFontSize*1.33/OriginalLabelHeight)

If I place this in the Size property of the label for the Date number, I’ll end up with a formula like this:

(64*LabelDate.Height/(64*1.33)*(64*1.33/120))

EDIT 3/28/19: As my backpacking middle-school math-wiz son points out, above can be simplified to:

OriginalFontSize * (CurrentLabelHeight/OriginalLabelHeight)

In the case of the Date label:

64*LabelDate.Height/120

Now it sizes much more nicely!:

Summary

Hopefully I’ve showed you in this post how to create a component, along with some approaches for resizing the controls inside.

The post PowerApps Reusable Components first appeared on Life on Planet Groove - Adam Toth's Blog.

Overview

In this post, we’ll look at how to use SVG images and some formulas to create a digital alarm clock style display in PowerApps. This is going to involve some image manipulation, so I’ll use one of my favorite free vector programs, Inkscape, to create SVG files that can be used in the clock display. I’ll also be using a free-for-commercial use digital clock font for this example (thanks to the author).

• Inkscape: https://inkscape.org/release
• Calculatrix 7: https://blogfonts.com/calculatrix-7.font

Create the Images

For the first part, we will need to create images for each digit of the clock 0-9, as well as the colon, AM/PM, and also a blank image (you’ll see why later).

Download the font to your machine. Unzip the package, right-click the TTF file, and choose Install Font (if you are on Windows).

Open up Inkscape, and create a new image. From File > Document Properties, make the image 36 Wide by 60 tall. For the units, choose pixels (px).

Click the Text Tool, and click in the middle of the image. In the toolbar at the top, change the font to Calculatrix 7, and font size to 36. If you don’t see a toolbar, choose View > Show/Hide > Tools Control Bar.

Type a zero “0”. Click the Arrow selection tool. Click the zero. We are going to center it on the canvas. Click Object > Align and Distribute. In the Align box, choose Relative to Page, and then click the buttons to center on the horizontal and vertical axis.

While the zero is still selected, change the fill color using Object > Fill and Stroke. Change the fill color. For this example, I’m using a bright blue LED color, R=90, G=254, B=254, A=255. Your image should look like this:

One last step, is to covert the font to a vector path, this is so that we don’t embed or need the font on the client machine. With the object selected, go to Path > Object to Path.

Save the image as “0.svg“. Repeat this process for the rest of the numbers 1-9.

Create two images for AM and PM (“am.svg” and “pm.svg”). Since these are two characters long, make the AM/PM images 100×60, instead of 36×60.

Create an image for the colon separator. I didn’t like the colon in the font, and the pipe character, “|”, and letter i “I” all looked alike. I made a custom implementation by stacking two separate commas on top of each other. I made this image 15×60. Name the image “colon.svg” and save it.

One last image to make. Create an image 36×60 completely blank, and save it as “blank.svg”. We’ll use this one in place of a number when the hour is a single digit.

Setup the PowerApp

Create a new blank canvas PowerApp, choosing the Phone form factor. Go to File, name your App (I called mine LEDClockDemo), and Save it. Always name and save your Apps right away to avoid losing work if your browser crashes!

Import the Images

From the File menu of PowerApps, choose Media. Add all the SVG files you created earlier. There should be 14 total images.

Add the Controls

Insert a button on this form, and move it to the top. Change the text to “Fill Data”. We are going to use this button to populate an array of Time objects, for each minute of every day. In the OnSelect function, paste the formula below:

ClearCollect(ClockImages,{Key:0,Image:'0'},{Key:1,Image:'1'},{Key:2,Image:'2'},{Key:3,Image:'3'},{Key:4,Image:'4'},{Key:5,Image:'5'},{Key:6,Image:'6'},{Key:7,Image:'7'},{Key:8,Image:'8'},{Key:9,Image:'9'});
Clear(Times);
ClearCollect(Hours, [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23]);
ClearCollect(Minutes,[0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59]);
ForAll(Hours, ForAll(Minutes, Collect(Times,Time(Hours[@Value],Value,0))))

Invoke the button’s OnSelect action by holding the Alt key down and clicking the button. You should now have an array called “Times” filled with a date/time object containing every minute of the day. You’ll also have an array called “ClockImages” that you can lookup Images by number.

Insert a gallery on to the screen. Change the data source to use the Times array. Change the layout to just display a title only. Your screen should look like this:

Edit the gallery template by clicking the Pencil icon on the first row of the gallery.

Insert an Image control into the template row. Change the Fill property to Black. Change the Width to 36, and the Height to 60. Set the Image property to ‘0’. Copy this image, and paste it 5 other times into the template row. Arrange them so they are all next to each other in a line. Change the third image to use ‘colon’ in the Image property. Change the last image to use ‘am’ in the Image property. Change the Width of the ‘am’ image to 100 pixels. You should now see something like this:

Add the Clock Logic

Now we’ll add in the logic on each number to control which digits display. We’ll try to account for 24 hour time display based on locale as well.

Click on the first digit. In the Image property, write the following formula:

If(Clock.IsClock24(),If(Hour(ThisItem.Value)<10,'0',Hour(ThisItem.Value)<20,'1',Hour(ThisItem.Value)>20,'2'),If(Or(And(Hour(ThisItem.Value)>=10,Hour(ThisItem.Value)<=12),Hour(ThisItem.Value)=0,Hour(ThisItem.Value)>=22),'1','blank'))

Click the second hour image. In the Image property, write the following formula. We’ll use a little string manipulation to our advantage, instead of lots of tests with numbers:

If(Or(Clock.IsClock24(),And(Hour(ThisItem.Value)<=12, Hour(ThisItem.Value)>0)),LookUp(ClockImages,Key=Value(Right(Text(Hour(ThisItem.Value)),1))).Image,LookUp(ClockImages,Key=Value(Right(Text(Hour(ThisItem.Value)-12),1))).Image)

Click the first minute image. In the Image property, write the following formula. The minutes are much easier to do, we can just grab the first or last character and convert to a number:

If(Len(Text(Minute(ThisItem.Value)))=2,LookUp(ClockImages,Key=Value(Left(Text(Minute(ThisItem.Value)),1))).Image,'0')

Click the second minute image, and place the following formula in the Image property:

LookUp(ClockImages,Key=Value(Right(Text(Minute(ThisItem.Value)),1))).Image

Now click the AM/PM image. In the visible property, put the following formula:

!Clock.IsClock24()

In the Image property, use the following formula to toggle AM/PM if displaying in 12 hour format:

If(Hour(ThisItem.Value)>12,'pm','am')

Your clock should now work and look something like this:

Conclusion

In this post, we’ve seen how to build a retro-style clock display with some svg graphics and formulas. We bound actual date time values to our clock, and used the formulas to change the displayed numbers according to the bound date/time.

There are of course questions: How can I easily reuse this on multiple screens? How can I change the color of the numbers without making new images? Right now these are challenges for sure, but as the platform matures, we may get things like custom font support, support for creating custom vector icons, and support for building your own PowerApps controls using React.

The post PowerApps Design – Create a Digital Alarm Clock Display first appeared on Life on Planet Groove - Adam Toth's Blog.

Connection.Connected

If you are building a PowerApp with offline capabilities, then it becomes very important to test whether the device has an active internet connection. The sensor function Connection.Connected
can be used to test for connectivity – if true, you are connected, false not so much. A common scenario is to check the result of this function in an OnSelect formula. If connected, write or submit to a live data source, if disconnected, write to local collection for submittal later:

OnSelect = If(Connection.Connected, Patch(Contacts, Defaults(Contacts),{Name:"Adam"}), Collect(DraftContacts,{Name:"Adam"}))

While developing your App, it’s somewhat difficult to test this in the web browser in PowerApps Studio, as the Connection.Connected function will usually return TRUE, even if you can’t connect to the internet (unplugged LAN cable, hotel Wifi without accepting terms of use, etc.). Even if you totally disable your network adapters, or put your computer in airplane mode, the property can still be unreliable. Sometimes it reports correctly, sometimes it takes a long time after changing connection status to update in the App, but usually just reports true.

Add to this the fact that if you are disconnected to test offline capabilities, then you can’t really make any changes and Save in PowerApps Studio, because, well, you are disconnected, right?

Fakin’ It

To get around this, you can fake it in the web browser. I call this Force Offline. It’s pretty simple to implement:

1. Create a new screen, name it Debug, and put a button on it. This will be a hidden screen, since we won’t make any way for a user to navigate to it.
2. In the button’s OnSelect(), set a global variable:

   Set(ForceOffline, !ForceOffline)

3. In the button’s Text property, change the label:

   If(ForceOffline, "Normal Connection Mode", "Force Offline Mode")

4. Now, wherever you reference Connection.Connected, wrap it in a check for ForceOffline mode first. Using the earlier example, you’d rewrite it like this:
   OnSelect =

   If(If(ForceOffline, false, Connection.Connected), Patch(Contacts, Defaults(Contacts),{Name:"Adam"}), Collect(DraftContacts,{Name:"Adam"})

Now, when you want to test, just go to that screen in Edit mode, and Alt + Click the button and put it into Force Offline mode. You can now test away as-if your app is Offline, change it back and test Online, all without having to futz with Airplane mode or disabling/unplugging adapters!

The post Testing Online Connectivity in PowerApps first appeared on Life on Planet Groove - Adam Toth's Blog.

Overview

The licensing page for PowerApps and Flow lists some quotas and limits depending on your license level, and can be a bit confusing. This post will attempt to clarifiy how exactly these quotas work in combination with particular license levels. Any specific numbers listed here may change over time, so they are valid as of the time of this initial posting (6/27/2018). I will keep the post updated if any of these numbers change, but as usual, you should refer to the official licensing page for the most current figures.

Maximum Flow Frequency

This limit creates the most confusion with my customers. The maximum flow frequency defines the shortest period of time that an automated flow trigger is allowed to check for changes. This maximum is based on the license level of the user who last edited and saved the Flow. Since flows run usually without any direct user interaction, there is no prompt for credentials when a Flow runs, so the Flow ends up running under the context and license level of the user who last edited and saved the Flow.

For Office365 Enterprise level licenses, this maximum frequency is currently 5 minutes. So this means that for any connectors that use a trigger that fires automatically, the test/check for the trigger’s condition (e.g. item created, row inserted, item updated, etc.) will only take place a maximum of once every 5 minutes for O365 E-level licenses.

This does NOT mean that instances of a Flow cannot be run more frequently than that. It just means that the check for the trigger condition will not occur more frequently than the max flow frequency. If the trigger check detects multiple changes in the backend system, it can start one instance of the Flow for each detected change immediately. Then the trigger polling mechanism will go to sleep and stop checking for changes again until the max flow frequency has passed.

Let’s look at an example for the SharePoint Connector, checking for items created in a list (but you can easily substitute rows in SQL Server connector, Tweets in Twitter connector, files added in DropBox connector, etc.). In this example, we are assuming the user that last saved the flow has an E3 license level (so a 5 minute max flow frequency):

• Flow has a SharePoint connector, with a Trigger on a SharePoint list for when Items are Created.
• The trigger runs at 1:10PM, and detects no changes. No workflows are started. The Flow goes to sleep and will not check again for the max flow frequency (5 minutes in this case)
• At 1:12PM, 4 new list items are created in SharePoint.
• At 1:15PM, the trigger check is again performed. 4 new items are discovered, so 4 new workflow runs are immediately started concurrently, one for each item.
• Next check for changes will occur at 1:20PM.

Notice in this example that when multiple changes are detected, workflow runs are spawned immediately for each change and run concurrently, they are not queued up, they do not stack up and have to wait for the max flow frequency to pass for the next run to execute. The max flow frequency simply drives how often the trigger conditions are checked for.

It’s interesting to note that you can control how many concurrent runs are started when the trigger fires. Most of our 1st party and 3rd party triggers use a polling system, where Flow checks the system regularly for changes. Most of these systems also have a way to return an array of changes in a single check. If you go into the Settings for a trigger (pull the ellipsis … down next to the Trigger and choose Settings), you may see a SplitOn section if the system is able to send back multiple changes with a single trigger change request. SplitOn determines the field in the trigger response that contains the array of items that has changed. You may also see a Concurrency Control section. If a system sends back an array of changes in response to a trigger check, you can control how many instances are spawned concurrently. Leave it off if you want to spawn as many as possible.

Automated Triggers

Automated triggers are subject to the maximum flow frequency. Automated triggers include the Scheduled trigger, and any other triggers not listed below in the Manual Triggers list.

Manual Triggers

Manual triggers are not subject to the maximum flow frequency. Manual triggers include the following:

• PowerApps trigger
• HTTP Request trigger
• Flow Button for Mobile

You can start as many flows as you wish, as frequently as you wish, using the manual triggers.

Maximum Flow Runs

The other quota your Flows will be subjected to is the Maximum Flow Runs per Month. Pretty straightforward – this controls how many instances (“runs”) a particular user is allowed to start in a given month. For O365 E-level licenses, this is 2000 runs per month per user. However this limit is pooled across the tenant, so if one user has reached the maximum, and another user has hardly used any, the unused runs will start to be consumed until the entire pool for all users in the tenant is exhausted for that month. If you start to hit the limit, you can purchase additional blocks of 50,000 runs for $40 USD / month.

Maximum Custom Connectors

The last quota to be aware of, which affects PowerApps as well as Flow, is the maximum number of Custom API Connectors that a user can create. With the O365 E-level licenses, a given user can only create a maximum of 1 custom API connector. This does not have anything to do with how many custom connectors can be used or referenced within a PowerApp or Flow, it’s simply how many custom connectors a given user can create. A Connector is a wrapper around an API or a service. A Connection is an instance of a Connector being used inside of a PowerApp or Flow. The limit here applies to the creation of the Connector– once it’s created, any Flow or PowerApp author can create Connections using the Connector without limits.

If you plan on needing multiple custom connectors created (maybe to be consumed in multiple PowerApps or Flows), then you’ll either need to distribute the creation of these across your developers, or you’ll need to purchase and assign a P1/F1 or P2/F2 license to the user that defines/creates the custom connectors.

Summary

Hopefully this post has helped to clear up some of the confusion around Flow licensing. If you have any other questions, please post a comment!

The post Microsoft Flow Quotas Explained first appeared on Life on Planet Groove - Adam Toth's Blog.

Setting a Person/Group Value

If you want to set a Person or Group column value using SharePoint’s REST API, there are a couple of things you’ll need to do. First, you’ll need to include the correct standard headers, including a X-RequestDigest value, If-Match header for consistency, Content-Type and Accept headers (easiest to use JSON for both), and X-HttpMethod. Here is a raw set of headers:

Method: POST
Accept: application/json;odata=verbose
Content-Type: application/json;odata=verbose
X-RequestDigest: <-- your value here -->
If-Match: *
X-HttpMethod: POST

…and a jQuery ajax example:

$.ajax({
    url:'https://contoso.sharepoint.com/_api/web/lists/getbytitle('TestList')/Items',
    method:'POST', // --> for any type of update, best to use POST, and set X-HttpMethod below
    headers: {
        'Accept':'application/json;odata=verbose',
        'Content-Type':'application/json;odata=verbose',
        'X-RequestDigest':$("#__REQUESTDIGEST").val(),
        'If-Match':'*', // --> Use an etag value if you want to ensure consistency
        'X-HttpMethod':'POST' // --> Only necessary for PUT,PATCH,MERGE,DELETE which some firewalls trap
    }
});

Next, the name of the column in your update is not the same as the actual column name, so you’ll need to append “Id” to the end of your column. For example, if your column name is “Requestor”, you’ll need to use “RequestorId” in your request body. Below is the raw body of a POST request updating both a single-value person column, and a multi-value person column. Notice the single-value column takes an integer ID value – this is the numeric ID of the user in SharePoint from the UserInformation list in the site collection. Also notice the Multi-value columns syntax, which requires an array object to be passed to it:

{'__metadata':{'type':'SP.Data.TestListListItem'},
'Title':'My title',
'SinglePersonColumnId':9,
'MultiPersonColumnId':{'results':[9,12]}}

Clearing Person/Group Values

To clear out or empty the values in person or group columns, how you do it depends on if the column is single-value or multi-value.

For single-value person columns, all you have to do is set the value to -1.

{'__metadata':{'type':'SP.Data.TestListListItem'},
'Title':'My title',
'SinglePersonColumnId':-1,
'MultiPersonColumnId':{'results':[9,12]}}

It requires an integer value, so null or empty string will give you an error: Cannot convert a primitive value to the expected type ‘Edm.Int32’.

For multi-value person columns, you have to set the results value to an empty array:

{'__metadata':{'type':'SP.Data.TestListListItem'},
'Title':'My title',
'SinglePersonColumnId':-1,
'MultiPersonColumnId':{'results':[0]}}

That’s it!

The post Set and Clear Person Column Values Using SharePoint REST API first appeared on Life on Planet Groove - Adam Toth's Blog.