Added that parent task because some partnerships are ended; we want to be able to include these partners, but hide them from other users.

It sounds to me like available/not available are statuses on a *partner*, and waitlist is a status on an *application*.

I want to explore this waitlist status a bit more. Is this a thing where coordinators are expected to keep track? Or is this a thing where it's best if the system keeps track - e.g. Partner can know about Maximum Number Of Access Grants Issuable, and then the system will automatically waitlist rather than approve applications once we hit that maximum?

Also, does this maximum number actually adhere to Partner? Or, for partners that have specific collections available, does it adhere to collections? (So, if you apply separately to Database of Kittens and Database of Mad Sciences, both maintained by Publisher McPubface, do we have 10 total access grants available from Publisher McPubface (that we can allocate however we like) or do we have 5 access grants to Kittens and 5 to Mad Sciences?)

The idea of the waitlist is that if we have distributed all the available accounts for a partner, users can still put their application in for access, but it's made apparent to them in some way that they are on a waitlist, and shouldn't expect an acceptance/rejection very soon. Basically 'Available, but not right now'. I suppose waitlist is in some ways both on the partner and on the applications.

I don't think we want this to be automated; it's feasible that we redistribute, have users not finish their account setups, and many other reasons that would introduce a discrepancy between how many applications the platform knows have been approved and how many accounts are actually available. I think coordinators should have the ability to set a partner if waitlisted as necessary, now that I think about it, if possible.

Also, does this maximum number actually adhere to Partner? Or, for partners that have specific collections available, does it adhere to collections?

At the moment, I believe all partners with collections have a number of accounts per collection. That might end up not being the case for some partners, but it shouldn't affect anything to assume it to be the case.

What does the workflow look like right now for coordinators who are managing waitlists? Is there some central source of truth for how many access grants are available? Do coordinators ever approve things and then move them down to waitlisted because they've approved more than the max #, and if so is that a feature or a bug? Are there pain points with the current waitlist workflow?

What does the workflow look like right now for coordinators who are managing waitlists?

Currently coordinators let users put their name on the waitlist, not responding or investigating applications until they hear that there are more accounts to distribute, either from us or the partner. Then they go through and accept/reject as before.

Is there some central source of truth for how many access grants are available?

The short answer is sometimes. Under the default 'partner-receives-emails-and-sets-up-accounts' method, emails are sent off to the partner and they get in contact with the editors to set up accounts. The coordinator then may or may not find out whether any individual user went through the full process to 'claim' an account. Sometimes partners share this information with us ("X users didn't respond to our email so distribute X more" or "X users have never logged in so distribute X more") but it varies from partner to partner.

Do coordinators ever approve things and then move them down to waitlisted because they've approved more than the max #, and if so is that a feature or a bug?

I'm not sure, but I doubt this happens very often. Coordinators should have some idea of how many accounts there are to grant total and how many they've distributed so far.

Are there pain points with the current waitlist workflow?

I don't think so, honestly. I suppose a way to notify editors, when they add their username to a waitlist, how long they should expect to wait (sometimes we know we'll have more accounts in the new year for example).

OK, I've done the available/not available part of this (not yet deployed but written & tested). The waitlist part requires more thinking.