Product Design
John Jay College
Brightspace Access Request Automation
A Microsoft 365 workflow that replaced emailed PDFs with a tracked, three-gate approval chain for Brightspace course access.
My role
Sole designer and builder
Company
John Jay College
Timeline
Live since September 2026
Outcome
[ Project hero image ]
Overview
Automating an approval process without automating away the judgment
At John Jay College, getting access to a Brightspace course meant filling out a PDF and emailing it to faculty administration, who reviewed it, signed it, and emailed it on to the LMS team. I designed and built a Microsoft 365 workflow that replaced that process. My premise was that automating an approval process should locate its judgment, not remove it: every request now moves through instructor, faculty administration and LMS approval in order, with a tracked status at each step. It is launched and in use.
The problem
Every request lived in someone's inbox
The pain was not one big failure. It was three small ones that compounded. Volume clogged the reviewer’s inbox, incomplete or incorrectly completed PDFs bounced back and forth until they were right, and finding a past request meant searching email. It mattered more than it might seem, because Brightspace holds FERPA-protected student data. Someone has to confirm that the requested access level fits internal rules before anyone is let in, so the review could not simply be removed to make things faster.
Inbox volume
Every request landed in the reviewer's inbox, so volume itself became the bottleneck.
PDFs that bounced back
Incomplete or incorrectly completed PDFs went back and forth before anyone could act on them.
No searchable record
Finding a past request meant searching email, so nobody could see where anything stood.
Student data at stake
Brightspace holds FERPA-protected student data, so someone has to confirm the requested access level fits internal rules before anyone is let in.
Context
I started by mapping the current process with the person who runs it. Then I asked, of each step, who actually has the authority to decide it, because that question matters more than the order of the steps. The tooling followed from the institution’s own constraints: what was already in its Microsoft environment, and where employee data was allowed to live.
Artifact
The Power Automate flow, showing both branches and the the approval gates.
The map showed three different kinds of authority hiding inside one email chain. The instructor controls who enters their course. Faculty administration sets policy over access levels. The LMS team knows whether a change is feasible and makes it. Seeing them separately is what made the design possible, because each one could become its own gate.
“
The course instructor should have the opportunity to approve who is coming into the class.
Process
Routing that follows who is signing
A Microsoft Form replaces the PDF and writes each submission to a SharePoint list. Power Automate then routes the request through up to three approval gates, using Microsoft Approvals in Teams and Outlook. Every stage writes a status and a timestamp to the list, and every rejection path notifies the right people, so an administrator can see exactly where any request stands without reading email.
01
Microsoft as a given, not a choice. The institution’s Microsoft environment was a fixed boundary from the start, and the form collects employee IDs, so that data had to stay inside it. I let that constraint choose the tools: Microsoft Forms, SharePoint, Power Automate and Approvals, all within the environment the College already governs.
02
Instructor approval before administration. Even for an observation, the person who owns the course should decide who comes into it. The chain follows authority over the course, not convenience.
03
LMS gets a real decision. The final gate is a genuine approve or deny, not a notification, so a request that faculty administration cleared can still be pushed back for missing information or timing.
04
A failure path separate from rejection. I designed Try/Catch scopes so a submitter learns when the flow itself breaks, without confusing that with a normal denial.
How I built it
I had never used Power Automate before this project. I knew the shape of the process, what each step had to do, and what the outputs needed to be to remain within compliance standards. Claude filled the gap between that design and the tool: it wrote the expressions, which I don't code myself, suggested the most efficient actions within each flow when I was torn, audited the design for likely edge cases against the scenarios I described, and helped me debug errors I didn't fully understand. It also shortened the learning curve by teaching me Power Automate in terms of the exact scenarios I was building for.
The design stayed mine since flow was built as I planned it from the start. Claude sometimes tried to overcomplicate the structure, and because I knew what the structure needed to be, I pushed back on functionality that was confusing or unnecessary. The result is that a design I had already worked out did not need a separate implementer to get built.
Two examples of how I directed it: Early on, the design Claude was heading toward assumed that urgent observation requests arrive close to the 24-hour minimum, so priority could be computed once at submission. I knew from the process that these requests are usually submitted weeks ahead, and that the reviewer's manual holding of requests was what kept the LMS queue manageable, so I rejected that design before it was built. I also held one standard throughout: if a behavior is not in the flow and I haven't watched it run, it doesn't count as done. That is why the reminder loop and the date validation appear under Limits and next steps instead of in the design.
Solution
A record that explains itself
A Microsoft Form replaces the PDF, and Power Automate routes each request through up to three approval gates. The course instructor goes first, because they control who enters their course, and that step is skipped when the instructor is the one submitting. Faculty administration checks that the requested access level matches internal rules, since an observer, for example, should never receive gradebook access. The LMS team makes the final call and confirms the change was made. Every stage leaves a timestamp, so the status of any request is a field, not a guess.
Final design
The full solution with all requested paths
Outcome
The PDF is gone. Requests now arrive as structured data, move through defined gates, and leave a timestamped record at each stage: submission, instructor review, administration review, sent to LMS, and processed by LMS. That record is searchable, which it never was in email. We are early in the fall term, so these numbers are early too. Peer observations are the most common request type. For requests that have completed, the median time from submission to the LMS decision is about an hour and a half of working time, counting only weekday business hours because that is when the LMS works, and the LMS step itself takes minutes. So far those figures cover requests submitted by instructors, who skip the first approval gate. The slowest stage overall is the one automation cannot compress, which is waiting on a person. It is not finished: date rules are still enforced by people, reminders are designed but not built, and the LMS team still makes the access change by hand. I will update this at the end of term.
The shift
From emailed PDFs reviewed by hand to one searchable record.
Before, access requests arrived as emailed PDFs, reviewed by hand with no searchable record. Now each request moves through the right approval gates and leaves a trace at every step, so where any request stands is recorded rather than remembered.
Reflection
What I learned
Looking back
Before launch, a seven-case session with the process owner and a senior stakeholder covered every rejection path and both happy paths. All seven passed.
After launch, a legitimate submission listing three course numbers failed, because one SharePoint column was still typed as a number. Fixing the column was not enough. Each Create item action in the flow had cached its own copy of the list schema, so the second branch failed on the same field until it was refreshed too. I audited the full list schema, converted the related ID columns to text, and wrote down the rule: after changing a shared column's type, refresh every action that writes to it, not only the one that errored first.
The first weeks also put the failure path to a real test. Three runs were rejected because a field was mistyped, so Power Automate stopped them before anything reached the record. Each failed run triggers a plain-language email that says the cause is usually a typo in a field such as an email address, course number or ID, not a problem with the access being requested. It carries a resubmit link and the response ID, so the failed run can be traced.
Still open
Date rules are enforced by people, not the system. Observation requests need 24 hours' notice, a 48-hour access window, and no weekend or holiday starts. The term field and some access-level entries also accept free text, so they arrive in inconsistent formats. Validation is the next fix.
No automated reminders. I designed a two-day reminder loop but did not build it. Early data shows why it matters: the longest waits sit at the instructor gate.
LMS still makes the access change by hand. This is an approval and routing system, not a Brightspace integration.
Ownership sits with me, by design, for now. The flow and its connections run under my account, which is a single point of dependency. I mapped what happens to each component if that account is removed, and re-authorizing connections is the one step that would need action. A formal transfer is deferred until my role changes.
Alyssa Jones © 2026