Product Design
John Jay College
Multiple Position Report Automation
An end-to-end automation of a faculty reporting process whose rules fold back on themselves: personalized links, conditional signing order, and a record of every submission.
My role
Sole designer and builder
Company
John Jay College
Timeline
Pilot in fall 2026
Outcome
In pilot
[ Project hero image ]
Overview
Designing a process whose rules fold back on themselves
Scoped to a pilot first
Every semester, hundreds of faculty members who hold more than one position have to report them to the College, and for a long time that meant a stack of PDFs moving through email. I am building an end-to-end automation of John Jay College's Multiple Position Report to replace that. The process looks simple until you notice that its rules fold back on themselves: a chair cannot approve their own form, so the route a form takes changes depending on who is submitting it. The build combines personalized email links, conditional approval routing through Adobe Acrobat Sign, and a SharePoint record of every submission. It is in final testing ahead of a pilot across three departments.
The problem
A yearly report run by hand
The difficulty was never the form itself, it was that the whole process lived in inboxes. The only way to know whether a faculty member had submitted, or whether a chair had signed, was to dig through email or check a tracker that was only as current as the last time the process owner updated it manually. Because progress was invisible, follow-up was reactive: reminders went out after someone noticed a gap in the spreadsheet, not when a form actually stalled. The exceptions were fragile too. A chair submitting their own form needs a different signer, and that rule had to be remembered and applied by a person every time.
No visibility
There was no way to see who had not responded or where a form was stuck without asking someone.
Rules that fold back on themselves
A chair cannot approve their own form, so the route a form takes changes depending on who is submitting it.
Every handoff was an email attachment
Forms moved as PDFs through inboxes, and each step depended on someone remembering to act.
One person, hundreds of forms
The process owner collected, validated, filed, logged and chased every form by hand, every semester.
Context
I started by mapping the current process with the person who lives in it. Walking through it phase by phase with the process owner, from the email that goes out to faculty to the Excel tracker she updates by hand, showed me where decisions were actually made and who had the authority to make them. That map became the spine of the design: every handoff that depended on someone remembering to act became a step the system performs, and every point where a person has to decide stayed a person’s decision.
Artifact
The process before automation: five phases, three roles, and a spreadsheet kept by hand as the only record of who had submitted.
The current-state map has five phases. The Provost’s office prepares and sends the forms, faculty complete and submit a signed PDF by email, and chairs review and sign. The process owner then collects, validates and files each form, logs it in an Excel tracker, and sends reminders to anyone who has not responded. Every handoff is an email attachment, and the only record of progress is that tracker.
“
In a multi-stage workflow, silent failure is the main risk, so every stage needs a visible record of what it did.
Process
Routing that follows who is signing
The part of the design that took the most thought was routing. A chair cannot approve their own form, so the signing order changes with who is submitting. A form with no outside activity goes from the faculty member to Academic Operations. A standard form goes from the faculty member to their chair and then to Academic Operations. When a faculty member is their own chair, the form goes to a supervisor in the personnel and budget role before Academic Operations. Buried under each routing is additional nuance determined by the content of the form itself. With that in mind, my goal was to cover as many use cases as possible.
01
Four templates instead of one.
Sign cannot require a signature conditionally inside a single document, so I split the form into four templates: no outside activity, outside activity within CUNY, outside activity beyond CUNY, and both. Fields that do not apply to a given template are left unassigned, so nobody is shown something they are not meant to act on. It is more templates to maintain, but it keeps each signer’s experience simple and puts the rules in the structure itself.
02
A confirmation page instead of a redirect.
My original plan was to send faculty straight from the form into signing. Power Automate’s HTTP trigger times out at 120 seconds, and that plan broke against it. I replaced it with a static confirmation page and let Sign’s own notification email carry the person into the signing step, which is more reliable because it does not depend on a single call finishing in time.
03
Native reminders where they exist.
Chairs and approvers already receive Sign’s built-in reminders, so I did not rebuild them. Only faculty needed a custom reminder flow, because they exist as people before an agreement does, and Sign has nothing to remind them about yet. Using what the tool already does well meant less to build and less to break.
04
Modular flows.
Kickoff, link routing, stage tracking, rejection handling and two reminder flows are each separate. A change to the rules or the wording of an email touches one place, and when something fails, the run history points straight at the stage responsible.
How I worked with Claude
I built this with Claude as a working partner for diagnosis and debugging, and I made a point of keeping the decisions myself. Two moments from the build show how that played out.
The first was about resisting complexity that hadn't earned its place yet. When we were redesigning how faculty resubmit a declined form, Claude was leaning toward separate static links or scenario-specific wording in the rejection email. I figured the link only had to resolve to one thing, so the email itself could stay the same and only the field reference underneath needed to change. Once I tested it live, though, the single dynamic link didn't work, so I went back to a two-link design. I try to take the simplest path until the evidence says otherwise, and then fall back on the design I already trust.
The second was about not letting a rabbit hole take over the test plan. While we were diagnosing an edge case, Claude suggested switching to a different detection approach. I wasn't disagreeing with the diagnosis. I just didn't think a half-understood edge case was worth holding up everything else, so I set it aside and finished the rest of the testing first.
That matches how I approached testing in general: I ran real submissions and read the run history, and I treat Claude's suggestions the same way. I check them against what the system actually does, and when I've watched the tool behave a certain way myself, I trust that over a cautious guess.
Solution
Each faculty member receives a personalized email link. Clicking it identifies them, looks up their chair, and creates an Adobe Sign agreement with the right signers in the right order. Every signature updates a SharePoint list, so status is a field anyone with access can check rather than something buried in an email thread. Declines use Sign’s native decline, which triggers a rejection flow that emails the faculty member a working link to resubmit, so a declined form becomes a clear next step rather than a dead end.
Final design
The automated flow: one personalized link, routing decided by who is submitting, signatures in a fixed order, and a record at every stage.
Outcome
The MPR automation has not launched yet, so there are no results to report, and I would rather say that plainly than dress up a build as an outcome. The build is complete and I am in the final stages of testing. What remains is a clean run through every scenario, including the edge cases and nuances that only show up when a form takes an unusual path, such as a resubmission, a chair who is also the submitter, or a deliberately incomplete submission.
After that, it goes to a testing group, so it can be stress tested under real-world conditions instead of only the ones I can imagine. I have defined what success looks like before that begins, so the results cannot be shaped after the fact. I will be watching the completion rate, the time from kickoff to final signature, how long chairs take to respond, and how many manual follow-ups the process owner still has to make. That last measure matters most to me, because the point of the project is a process that no longer depends on one person remembering to chase. Once the testing group has run it, I will report what happened here, including anything that did not work.
The shift
From a tracker kept by hand to a status the system keeps.
Before, progress lived in inboxes and an Excel tracker the process owner updated herself. In the new design, every signature updates a SharePoint list, so status is a field instead of an email thread. The measure that matters most to me is how many manual follow-ups she still has to make.
Reflection
What I learned
Looking back
Testing is where the design met reality. The costliest bug was a Sign field assigned as a prefill, which silently stops an agreement from ever activating. Later rounds found chair routing sending every submission through the wrong signer and a resubmit link that did nothing. None of it announced itself. I found each one by running real submissions through the real system and reading the run history. The lesson I took is that in a multi-stage workflow, silent failure is the main risk, so every stage needs a visible record of what it did.
Alyssa Jones © 2026