Today SPs that want to use SeamlessAccess need to fill out a form in Airtable to request that their domains be whitelisted to be able to access the service. This is ONLY required for implementers that are ding the “Advanced flavor” of implementations. Those using the “Basic” and “Standard flavors” will not need to whitelist the call to API in these instances is made directly by SeamlessAccess.org.

The process

Those implementing the “Advanced flavor” of SeamlessAccess.org, will be directed to provide a request to whitelist the domains that they will be using when making API calls. Their request is shepherded through the process manually:

#

Step

Performed by

1

SPs send requests for white listing by filling in the form https://airtable.com/shrW1gq06nMazByEt. This request generates an email to laura@seamlessaccess.org

Requesting SP

2

Requests are forwarded to the Operations team at ???

SP Outreach

3

Once a week (on Fridays), the requested domains will be (manually) whitelisted.

Operations

4

White listed domains will be added (manually) to the  Seamless Access Configuration Parameters list. SP Outreach is informed, by ???

Operations

5

The whitelisted domains list in Airtable is updated to indicate that the request has been fulfilled, and requestors are informed via email.

SP Outreach

Request form has a predetermined list of organizations! What about those not on the list?

Q: Submitter can pick only an institution from the list. What happens if the institution is not on the list?

A: In the intro text, individuals that don't find their names on the list are asked to contact me. In reality (and especially for the beta period), I don't think we want any organizations that we haven't been talking to gaining production access until they have spoken to us. All of the organizations that I have had any contact with (or have been mentioned in email threads) are already included in the database and will be available for selection

Who can submit a form?

Q: Is there any authentication mechanism behind sending a request. At least to check the ownership of the submitter email. If not, then anybody can send request impersonating the submitter. 

A: You're right. This is not designed for high-throughput, unchecked requests. As currently implemented, it is assuming that I am in direct communication with the individual making the request because we're working with them directly on a Beta implementation. That said, it is possible to put in authentication and/or other controls. I just haven't.

Who gets requests? How are they processed?

Q: Can you please explain the notification flow which is happening in the background, which parts of it are automatic and which need a manual intervention  i.e:

  • Who gets notified after submitting the request? 
  • How is Leif/Operations team notified, is this part of the same automatic notification flow? 
  • When Leif/Operations team makes the configuration who and how do they notify? 
  • Who makes changes in the airtable, marking the whitelisting done? I guess that changing the air table triggers the notification to the requested that it is done?

A: Currently, when the form is submitted, an email is sent to me. I would love for it to be forwarded to a mailing list that includes you, Leif (and others as needed). This is trivial to set up; Heather would need to set up a mailing list that contains these individuals, and I can set up forwarding rules so that this distribution group gets the request. Note that Airtable does have APIs, so it is likely possible to push requests somewhere for a system to process them directly. (but then we'll probably need a bit more structure on some of the free-text fields in the form.)

At the moment, I am forwarding the requests that I get. At the moment there are only 12 organizations that have indicated that they are working on an implementation during the beta period (through June), so manual processing is definitely do-able.

Leif indicated that he would like to process the requests once per week on Fridays. I think that process probably needs to be put into place. Once the request has been processed, someone needs to update Airtable - It can be me or Leif/Operations, whatever makes sense. If Operations makes the change to check the boxes, it can be used as a trigger notification to me to notify the requesting party. Or, you guys can just send me a note to let me know and I'll check the boxes and follow up.

How urgent is it to get something else in place?

Bottom line, though, is we should do whatever makes sense for this early phase of the project. Clearly what is currently in place will not scale as-is. I'm guessing it will take a while to get to the point where we are processing large numbers of requests each week. I expect it will stay in the 0-2 requests per week for quite a while (particularly since it is only those implementing the Advanced Flavor), so we likely have time before we put in place something very durable. This process also will need to include other onboarding activities like signing the terms of service, reaching out to SPs for document their user stories and get them listed on our site, etc. 

  • No labels