Power What? (2/2)

My first productive Power App was born of frustration.

Bit of background: I’m the administrator for our global SAP Cloud for Customer tenant. Let’s just say our rollout was a bit… haphazard. Partly due to our partner, mostly due to internal reasons (but that’s a post for another time). The long and short of it is that we ended up with a smattering of offices using the system with no real support proceed in place, but one common link — me. I’m the one who led the preparation, config, and onsite adjustments during our phased rollout blocks, so I’m the name and face everyone thinks of when they have a question or need help.

This seems to happen to be a lot. Clearly I should work on being less helpful.

Anyway, this resulted in my inbox essentially becoming the support desk for the system. Which is really not a great experience for anyone involved. We tried a few things to alleviate the problem: using our first-line IT support team for triage (they just bypassed it); writing sorry documentation for our local team leaders (they didn’t read it); even giving a colleague access to my inbox so there was theoretically less chance of something being missed (yes in hindsight that was a bit silly). Nothing really fixed the problem. I even asked if I could use the ticketing system IT were using, but that didn’t really get anywhere.

Hang on. What if I build my own ticketing app?

Here’s where I should really give you a nice documented description of the build, resplendent with screenshots and tips and lessons learned. However, seeing as how I started writing this some…. 5 months ago? and still haven’t managed to sit my a*se down to retroactively document something I’m not particularly proud of anyway (and may or may not even still exist), I’m just going to leave you with a Very Brief Outline (VBO) (can I trademark this?)

  1. I started off having a good dig through Microsoft’s ticketing app template. This used Excel as a data source–which trust me, you never want to do, ever, don’t even think about it–but I took these principles to create my own version.
  2. I set my app up using SharePoint as a data source. This meant I could use our existing organisational security groups to grant access, removing a lot of database headache. Also meant I could easily manually check and manipulate the data. Which, let’s face it, you’re going to want to do when you’re building your first app.
  3. I kept the initial design simple, but there were certain key elements I knew I wanted:
    • Separate User and Administrator views;
    • Quick dynamic search within any list of tickets;
    • Being able to see completed tickets (more as a safety for myself for if[when] I accidentally closed something I was still working on);
    • The concept of You Cannot Trust The Users So They Must Be Controlled. Er. …. Restricting user input to key fields, so as to enhance ease of use. That sounds better, right?
  4. I quickly moved into iterative design without realising it. In true James fashion… First, reach a milestone. Then, test the thing yourself. Next, take note of what pisses you the heck off the most. Go fix it. Rinse and repeat.
  5. Finally I had a working prototype I could share with some of our users. This of course moved us into iterative design mark II: very much like my personal testing, except swap ‘what pisses you the heck off most’ with ‘what the users are doing that pisses you the heck off most’.

Yes I’d love to say my first app was ‘all about the user experience’, but quite frankly it was more about reducing inane questions and nonsensical actions that I would have to fix… Hey, it’s a working strategy.

The app actually completely bombed in the end and we quickly entered up back in Inbox Nightmare. But that’s less to do with the concept and more to do with my lack of implementation strategy. And that’s a post for another time…