When Forms makes no sense

When I developed our Support Desk app our screens were developed using Forms, these offer certain benefits I required, particularly with handling attachments uploads. However, once we’ve moved to managing of tickets use of forms wasn’t strictly necessary and actually has become a hindrance.

Why? When it comes to assigning a ticket to one of our team members the dropdown needed to refer to data in a separate SharePoint list, something forms just won’t let me do. Thus, I’m now creating a new ticket management screen, including adding some new functionality at the same time.

What spurred this latest iteration for the app was my desire to allow quick ticket assignment of a ticket from within the gallery, just click a person icon and it assigns to you. This worked, however when I would then open the ticket and perform a task (after refreshing the data) the data actually resets to what it was before I’d made the assignment – weird!

So, I decided to abandon use of forms and take control and thereby gain greater functionality. I now have the ability to control who we can assign tasks to, previously we had to search a combo box. The negative with losing forms is of course being able to leverage the OnSuccess and OnFailure events, these are so useful.

I’m adding to this iteration tabs and work notes. The tabs will help us reduce scrolling to see comments blocks, especially as were now adding another comment block, tabs can be used to control visibility and improve usability. Still much to do and test, but liking where this is going.

Develop. Use. Enhance.

We’ve been using the Support Desk App I developed for about two months now, long enough to determine things we like and don’t like.

It’s funny how when you develop something at the time it can seem perfect, then you use it over and over and that feature comes to annoy and you want to replace it. For me it is the screen that lists all tickets in the system. I developed it such that it can list all tickets or you can filter to just a particular status, fine I thought at the time, however, as we got more and more tickets I really wanted to just see ‘active’ tickets, that is a grouping of all those tickets that weren’t rejected or closed; I hadn’t thought to include this.

Another feature I’m wanting to add to this same page is to limit the listing to those tickets assigned to me. One of my team highlighted I’d created comments within the system yet had forgotten to add notifications for when people added these; people expected this and were adding comments thinking we were being notified; I added a flow today that is relatively basic:

  • When a new comment is added to the comments list:
    • Get this item
    • For that item, get associated ticket to determine who creator was
    • Notify creator and systems team of the comment

I’ve also started on enhancements to logic associated with the gallery that is used to search tickets, swapping out IF statements for SWITCH as I implemented more complex logic to allow adding show active to the mix.

I still have enhancements to make to combo boxes, so far these have defeated me when connecting to my SharePoint lists and allowing me to limit to just our team, keep running into PowerApps talk to the hand 🖐🏻 ever helpful it is. Hoping to explore UI Flows at some point having set up our server with the requisite permissions last week.

Versioning: There’s a catch

With developing our support desk app at work I’m often saving and have a habit of also just hitting publish, it was only me after all. A mistake perhaps, there’s umpteen million versions there now. I made a mistake the other day when doing something, I was merging the contents of my previous Category 1 Self-Assessment app and suddenly needed to revert, but which version contained the correct code? I honestly couldn’t tell.

In the end I was forced to revert to a time where I thought my app was likely last minus the issue but I wasn’t going to lose all my development efforts as well, a fine balancing effort.

Today, I was making some edits as I’d already noticed two of the combo boxes had lost their associated code, then checking I noticed all my additions associated with Concurrent() weren’t there, nor were some recent code connected with the merge. I’m going to be a bit more careful in future and will look to document code I use on screens so I’m not set back as I’ve been today.

Stumbling into context variables

As I was developing our Support Desk app, I decided I wanted to provide our Systems Team the ability to link directly to tickets from emails I was sending. I had found relevant PowerApps community support emails that detailed the information I needed, I added this to the relevant part of my Power Automate Flow.

Within the PowerApp I added the necessary code to check whether the Param(“theTicket”) existed before navigating to the relevant screen and providing relevant context variables. I thought that was going to be all I’d need to know – oh bless, not so. Initially, I could get the gallery to filter to just the specified ticket number, great, however I wanted functionality for our team to then eliminate this filter and then show all tickets once more. Here is where I stumbled, tripped and fell over context variables.

You see, I hadn’t read anything relating to these variables and had no idea really what they were, hence why they weren’t working for me as I thought they should. I had added a Filter Icon, when pressed it was supposed to disappear and reset the gallery so it has no filter applied. Hours later, once I worked out (stumbled upon) context variables functionality, all magically worked. Ironically, it involved my deleting variables that I was creating within the screen and relying upon those I was calling the screen with.

Over the weekend, I was doing some online training with Microsoft that provided further clarity to a variety of topics, which I forwarded to my work email account for reference. Still many modules to run through, which is good to have.

My conte}{t

My development experience with PowerApps to-date has been somewhat limited, I’ve developed one application in late 2018 and am again developing another right now.

My first app

I work within a Research Office at a local university, and in 2018 the Australian Federal Government advised us that the way Category 1 research grants were to be determined was to changed, instead of their advising us of the list each year, the Australian Competitive Grants Register (ACGR), we would now follow a defined process to self-assess whether grants met these requirements. Thus, rather than relying upon spreadsheets we determined an online app using Office 365 tech was the go.

My first app took me four days to develop, thankfully I had the benefit of having sat with an external consultant on two occasions relating to a separate application’s development and had taken notes relating to tricks and techniques (e.g. use of collections) which helped me with my own development. Perhaps the most difficult thing for me, a web designer/developer of many years, was connecting with Flow, I found interacting with this difficult initially (and still do) as documentation is scant here on how to identify, how to remove a variable if you add a dynamic variable in Flow but no longer require it, and the list goes on.

My biggest gripes

Perhaps my biggest gripe in working with PowerApps has been the level of documentation that’s provided. I’m a PHP developer and am used to a plethora of documentation as well as good community support, contrast this to scant documentation provided by Microsoft for their product, seemingly relying upon their community to do their job for them. There’s nothing wrong with having a strong support community that enhances your documentation, however they should not be considered your documentation.

Not too far behind this is PowerApps itself, well rather the interface to be exact here. Is it not the pits to work with? I think so. That formula bar would have to be the worst thing I’ve ever interacted with since the VHS Video Recorder and having to rewind a tape. I would dearly love to see a full desktop application that supports multi-desktop in which design gets separated from code and error messages. Most developers do have multi-screen, so it makes good sense that we have the option to have a fully fledged developer app and one that gets rid of that damned awful single-line (that you have to drag to see all your code – WTAF!) and replaces with a full-screen code environment.

App Two

A few weeks ago I started developing my latest app, an issues tracking come support desk app that will be rolled out within our office. There have been days I have sat there and wanted to throw my Dell out the window, if I see another delegation error. My initial SharePoint lists design had been based upon how I would design using MySQL or Oracle databases, I have quickly discovered the limitations of working within a PowerApps and SharePoint environment, you get a bloodied head, quickly.

I started out with lists to represent our systems and our team, instead each has now been incorporated within the Tickets list as a Choice type (an enum type in traditional databases). This has allowed me to get around the delegations issues that plagued me, not to mention simplifying the structure. This past week I worked on implementing the ticketing top list whereby our managers and team leaders will be able to add up to 10 items, reorder their list, and remove from the list. I gave up on doing reordering within PowerApps, it could only handle first/last items, other placed items required my sending out to Flow (now Power Automate) to handle de-listing an item and then reordering.

I’m currently battling with adding attachments, I’ve got to discover the ID number of the added ticket as Flow creates my item as attachments cannot be added until the ID is know. Sometimes I think Everest seems smaller. I’ve only this coming week to complete development before they want to launch and need to also add additional Flows to notify of changes, our management of tickets, and potentially creation of a log which doesn’t exist, though that is simple.

A loss of rules

I was disappointed to hear Microsoft had decided to remove Rules from PowerApps. It is currently at deprecated status, thus your can turn this on within the settings area of the app at your own peril, however it is a disappointing loss. My first app needed to be re-coded as it relied heavily upon rules when developed and certainly made development easy once your wrapped your head around how they worked. Microsoft has said these were not commonly used and were poorly understood, hmm, I wonder if this was yet another case of crappy documentation?

Settings to enable the basics

One final thing before signing off my first post, I found it absurd that I needed to head into settings to turn on a setting to enable my app to support the use of Blank() so that I might write null values to a SharePoint list. Does anyone else find this absurd the inability to write blank values by default? This is default functionality in other languages but Microsoft seems to think otherwise and necessitates your enabling it. I might add, it is not obvious which setting you need to turn on, rather it is turn on all except rules and test. Poor form.