Recently we decided we’d like to start capture how much effort was expanded working on our tickets. Reason being, assumptions may be that tasks may take little time when instead they may actually consume far more time, recording this would allow us to demonstrate this via PowerBi reporting.
I quickly added a time estimate field to our tickets SharePoint list and thought we were home and house. It all looked as though things were patching, then today I noticed statuses weren’t updating, weird. As soon as I removed the field from the patch statement all worked again, seemed it didn’t like having a number text entry field, it wanted it to be a text field and have that converted to a number, queue X-Files theme music.
After launching the latest update to the Support Desk app I was working in our section of the app, excited to the tickets list then re-entered to view this items data. The previous ticket I had updated its status to closed and this ticket just selected has a status of new, however it was restraining the previous ticket’s status; a bug was discovered.
With redeveloping the app I had swapped away from PowerApps forms as I needed to mix form elements from two SharePoint lists. Swapping over meant losing use of NewForm() that just resets everything for you, as I just discovered. I found it was best to apply resets to form elements as I exited the screen, using the screen’s OnHidden event, also applying first thing as I enter the screen via OnVisible, just for extra insurance.
Thankfully this was an easy fix and bug quashed. I hope they beef up forms functionality to support more complex builds.
Ever since swapping away from my 365 account at work to a service account for PowerApps development we’ve experienced issues. Most notably, Power Automate flows just seem to fail where previously they never did. So, I rebuild these flows using the Service Account, reconnect everything within the PowerApp, and things just work once more. The flow doesn’t have a single step changed, or any new connectors, just ownership.
One thing that truly irks me with PowerApps development is adding a flow to your app, why when doing this must Microsoft insist on wiping out all other codes from the formula bar? It’s seriously annoying, right? Having to remember to copy your code prior to insertion of a new flow truly sucks the big one.
I recently was forced to replace one flow that was used to handle approvals as it kept flaking out on me. In creating the new one under the service account I decided to turn off the old one as this would then indicate to me if someone was running a cached version, which occurred today.
I decided there needed to be a way to highlight to our users when we’d updated our app, something we could announce to them for comparison. I eventually discovered how to go about achieving this, firstly adding the PowerApps for App Makers component. Through this component you’re then able to discover data about apps, pulling this into a collection.
ClearCollect(GetApps,PowerAppsforMakers.GetAppVersions(Last(Filter(PowerAppsforMakers.GetApps().value,properties.displayName = "My Apps Name")).name)); Set(theVersion, Lookup(GetApps, First(GetApps.id), properties.appVersion))
I found when collecting the apps data for my app I was getting several rows returned, the last row contained the most recent published version. I then use a lookup to store this into a variable which I later use within a label for display. The version data displays date and time the app was last published, this makes it easier I think for users to identify whether they’re using an up to date release, version numbers I think have less meaning.
Sadly, I can’t get around the catching issue and must get users to remember to either clear their cache or force refresh to ensure they’ve the most recent version. I’m about to publish a much more substantial update to our service desk that incorporates:
Variable-height galleries with rich text support for comments
Introduction of private work notes for our team
Dynamic save button (mainly to accommodate the new tabs – I didn’t want multiple save buttons – bleh!)
Smarter forms for task assignment
Looking forward to deploying this new release, I think the team will enjoy using it.
I spent time today redeveloping our Support Desk app, and as I was doing so I stumbled upon someone’s suggestion for how to handle a successful patch event. In my previous post I mentioned one negative in not using Forms was losing the OnSuccess/OnFailure events and the facts these don’t exist outside of Forms.
Quite ingeniously, the person’s post I stumbled upon today suggested use of a collection to store result of a your patch command:
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.
Wrapped up enhancements to our support desk app today, realising the edit screen reserved for our systems team lacked the comments section that was currently located on the view screen. We’d decided earlier in the week to optimise workflow by not requiring us to click the edit button to then take us to the edit screen.
So, when creating the new edit with comments screen today I came across THE MOST ANNOYING BUG in the forms dialog where you add fields and set whether they’re view/edit, and type of view/edit. Two of the fields are rich text fields, upon specifying the first to be rich text edit the field would then drop it and several others I’d added to the bottom of the list of fields. What the heck? The bug only occurs for the first rich text edit field and not when you set subsequent fields, but is seriously annoying.
Another annoyance is forms layout. Why if they auto layout can they not provide facility to specify this field should span n elements? Having to manually drag and then correct placement of things is so 1990s.
Sometimes you just need to take time and read things, don’t you. Last Friday, I was looking for solutions with developing our Issues Tracking app at work that would allow me to support upload of attachments. The column existed, however I was struggling with sending my content from PowerApps > Forms then discovering what the created ID field was within the Tickets list. I’d been attempting to have Forms return the ID value to no avail.
Then, within the final minutes I noticed that Edit forms might be the way to go. I hadn’t actually used one, and I wasn’t about to invest the effort this late on a Friday afternoon; perhaps I should have, I barely slept the night as my mind was abuzz with what might be. This morning I arrived early to work and set to task, creating a new screen and adding an Edit Form.
What is interesting about the use of Forms is their auto layout; select the number of columns, the visual layout of elements and their labels (vertical or horizontal), and then select which fields you want. Interestingly, not all fields are added when you select your data source, I was forced to add additional fields each time. Another quirk associated with layout, fields are laid out on-screen in horizontal order depending upon the number of columns you selected, so if you had selected a two column layout these are ordered thusly:
Whilst basic field layouts are relatively easy, adding multi-line fields to the mix soon throws layouts askew and whitespace can appear everywhere. Indeed, today I needed to rethink the layout of my forms several times to maximise layout and minimise whitespace, in the end all working quite nicely.
I was surprised how easily the Edit Forms made creating content within SharePoint lists, most especially those attachments I had battled with throughout Friday, taking just 30 minutes. Once I had created the screen, added the Edit Form object and specified the associated table, selected the desired fields and connected to a button with NewForm(Form1).
Our app is ever closer to being finished now, I’m just constructing the comments functionality now, this needing some adjustments to the list to support working more easily with Forms. For me, another added bonus working with forms comes in the form of the OnSuccess and OnFailure events, these can be used to perform tasks based upon outcome of submissions, for example, where successful then subsequently reloading my collections and refreshing the galleries. Previously, I was relying upon a timer post-submit to add a delay after which I would do this, hence why it pays to read sometimes, you can save yourself a bit of time in the long run and clean-up down the track.