Annoying forms bug

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.

Frustrated enhancements

Following on from yesterday’s development efforts I continued enhancing our support desk app with further features and changes we were keen to implement.

As I was developing it was frustrating the poor documentation on the PowerApps website, funnily enough there was the comment reflecting this from someone who mattered subtlety “incomplete documentation”. It’s poor they fail to document how to use features or attributes sufficiently, even sometimes at all, in this case I was looking for information relating to the ComboBox and setting default and defaultselected, there wasn’t a thing, you are expected to rely solely upon community documentation for support; thank heavens that exists, if you can find what you needed that is.

Today, I split functionality depending upon use when we look at ticket details, support team going straight to edit mode whilst users only view, thus we’re saving a click each time. Also, I added a new tickets list mode I should’ve thought to develop right up, active tickets. Having this listing makes such a difference now we have so many tickets in the system now.

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.

Affected connectivity

After migrating to our service account from my personal account a few weeks ago, flows have either worked or experiences issues with their connectivity. It’s weird, all were migrated in the same manner, yet one or two have experienced failures and have needed to have their connectivity to the service account added again. Thankfully, the affected flows are only monitor and don’t stop parts of the service desk working, it’s just annoying.

Perhaps more annoying is the fact I can’t remove my own account as connection from anything, as creator of everything all connections from my own account remain and cannot be deleted. I’ve assigned the service account ownership, but cannot remove from myself, why?

But do they have permissions?

Both apps I had been developing recently got pushed to staff in our office yesterday. We had been waiting for the IT department to create us a P1-level account, however they’re under load as result of Covid-19 and staff now moving to Work from Home, so our account request has been pushed back for now.

In pushing the apps out via Microsoft Teams yesterday, this was the first time these were being run by users outside of my immediate team who had ownership rights to the apps. Danger, Will Robinson! Immediately there was an issue, one of the newer staff, not a member of an older group assigned access, contacted me to advise there was an access issue. The app was loading but one or more of the connected SharePoint lists was not assigned appropriate permissions to allow her access.

I noticed some of the lists had assigned rights to an older domain group (we changed names in mid-2019), so all SharePoint lists I was using needed to be checked and the new group applied with edit rights. Unfortunately, that user hasn’t had time to return, though another within her team used my newsletter article submission app to submit several articles successfully, so updating of permissions has clearly worked as intended. Learning I need to check these things before publishing, part of my processes going forward.

Newsletter submission app, with attachment support

When I took over coordination of our e-newsletter several years ago the first thing I did was change how people submitted articles, making it more in line with the corporate equivalent. I decided to utilise the Qualtrics survey system as it wasn’t going to cost me anything, whereas using Survey Monkey would have, and I could use branching to control the questions they would be shown based upon selections made.

Whilst this has generally worked well, output from submissions isn’t the best and there’s no way to support formatting of content, which can sometimes be useful when submitting articles. Enter PowerApps.

I created a three screen app, screen one presents a visually appealing introduction advising users what we accept and reflects the current visual of the newsletter. Screen two is our submission form, implemented using a PowerApps form connected to a SharePoint list. Screen three provides feedback their submission has been successful and allows them to submit an additional article, if required.

The form note allows rich text article submission and to specify more richly event details, such as start and end dates and times. As the SharePoint list isn’t accessible by all members of the newsletter team I needed to be able send all details of the submission, including attachments, in an email to our email address, here I initially hit a stumbling block.

Yesterday, I managed to locate the required steps to support my needs, the process coming down to:

  • When a new item is created
  • Initialise a variable – AttachmentArray (type: array)
  • Get attachments – linking ID to step 1
  • Apply to Each – The output (Body) from Get attachments
    • Get attachment content – Id (ID) from step 1; file identifier (Id) from Get attachments
    • Append To Array Variable
      • Name: AttachmentArray
      • Value: { “Name”: @{items(‘Apply_to_each’)?[‘DisplayName’]}, “ContentBytes”: @{base64(body(‘Get_attachment_content’))}}
  • Send an Email from a shared inbox
    • Attachments: AttachmentArray

The use of base64 ended up being the clincher, I’d tried other people’s suggestions but nothing worked. Oddly enough, the error associated with not using base64 returned was related to subject and person fields. I’m on my iPad so don’t have the original Microsoft mvp link to share just now that helped resolve my issue, his code above; so grateful!

Old for new

Some years ago now I took over coordination of a research newsletter at work. When I first started in the office they were still using Microsoft Outlook and a listserv to handle distribution, old tech at its worst. Before taking over I worked with the then coordinator to move it to an email marketing platform.

The decision freed us from being tied to a desktop and an individual’s computer, it also enabled us to track user clicks for the first time – what is our audience actually interested in? Later, I developed an online form using Qualtrics, typically used in surveys, to allow people to submit articles for consideration.

Sadly, the notification emails I’d receive from Qualtrics were just awful. It was often easier to click the link within the email sent and wait for it to load rather than try read the email sent.

When we first started using PowerApps and other Office 365 apps I knew I wanted to investigate these for replacing Qualtrics. I had thought Forms the logical choice, however this is actually quite limited in its functionality, thus PowerApps was a more logical choice. With some quiet time yesterday I set to task and banged it out quickly, adjusting today with additional date fields to support events.

Once I confirm my right to deploy beyond our office, and set up a flow to email submissions, I look forward to finally progressing our submissions system.

Refine. Revise. Let’s restore

Following our first demonstration of the Support Desk app to our administrative teams the decision was made that perhaps allowing users to enter titles could get messy, let’s instead standardise via categories and hide the title field in SharePoint.

All sounded good at that meeting, until I went to implement within the app itself and noticed how our limited number of categories was going to appear in gallery listings used to show the tickets, and again in the area where managers and team leaders priorities tickets. Where before the uniqueness of each title made each ticket easy to read, now the category titles used was making everything confusing.

Speaking to my supervisor today in our regular catch-up, I suggested titles needed a revival within our app. So, we’ll be keeping both going forward, though will provide users with suggested text per category to try avoid junky titles being entered.

Next, to inflict upon several users for testing. Hopefully I.T. approves our service account soon enough so we can stop running under my personal one, always fun come password change time.