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.

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.

Discovering concurrent

Following my foray into Microsoft’s online learning for PowerApps development, here they mentioned tricks for improving the speed of your app.

One suggested trick was to look at where you were making multiple calls to external data requests and wrap these with the Concurrent() command. The benefit of using the command is that rather than multiple individual calls to SharePoint for data, a single more efficient call gets made.

Yesterday, I finally remembered to implement the command in my service desk app, this has multiple calls at different points throughout where it’s either gathering the data or having to refresh data. Before implementing the command there was some lag in loading the app, nothing huge as it’s not that big an app, but noticeable; post-implementation, I have noticed the app is certainly more speedy to start-up and when it is required to interface with SharePoint directly rather than just via collections.

Am looking forward to continuing the online learning, has certainly been beneficial thus far.

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.

Into the Flow

As we get nearer to launching the Support Desk app I’ve been developing, I continue to refine and enhance Flows I have developed to support the app. In particular, I am enhancing those Flows that are built to inform our team of those tickets that remain open (status isn’t closed or rejected). My original Flow was more basic when developed, purely spewing out all items, formatting to a table and emailing that list:

Get Items
from SharePoint List; filtered to exclude Closed and Rejected; sorting
Select
Specify those columns I’m wanting and use functions on some data
Create HTML Table
Compose
Apply a class tag to <table> tag
Send an email using Corporate Email

Whilst my initial attempt did work, there was a flaw in that all ticket types were listed together, that is those that had a a deadline and those that did not. I wanted to refine this further to draw attention to those with a deadline so we would pay attention to these first, then list less time-critical tickets below these. To do this, I needed to create a branch above the existing Get Items, thus two exact streams would exist building tables, one each for Tickets with Deadlines and Tickets without Deadlines, then at the the data would merge to create the email.

Daily schedule to produce a grouped list of open tickets

I’m still struggling with trying to format the URL that is created per line in the Select command. I’ve not yet managed to convert from vanilla URL to a friendly link (e.g. ‘LINK’). I’m not giving up just yet, hopefully before we go live I’ll find my nirvana, though at least it’s just our team and we can live with these links rather than farming them out to our user base.

Time for multi-window desktop app

The PowerApps development environment is due an overhaul I think. Currently all is confined to a single web application window where errors, attributes, code, visual and application hierarchy must coexist, it just gets a bit cluttered. I know I find myself struggling for space when trying to debug errors and my function/code area is expanded such I cannot see the error panel, this i must close the code to examine the error, then reopen to begin correcting. Sadly, I lack one of those beautiful ultra wide monitors that arrived on the market in recent years.

To that end, I wonder is it time for Microsoft to launch a fully fledged desktop app that supports multi-window development? Where we might separate our code on to a separate window along with the errors panel, and others as required, bringing the “Power” to PowerApps. I hope they are considering this already on their roadmap, I’ve concepted this utopia below borrowing screenshots and someone who kindly looked like they might be coding in front of one of those beautiful monitors – I dare to dream, hey! Yet to convince work of my need.

PowerApps utopia? Being able to work in a desktop app and multi-window environment. Microsoft, please!

Using Forms speeds up dev

KEEP CALM and read the manual

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.

Edit Forms

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:

Field 1Field 2
Field 3Field 4

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.