search

bcgov / entity

ServiceBC Registry Team working on Legal Entities
Apache License 2.0
23 stars 58 forks source link

Relationships Edits to API Info Session Slide Deck #7035

Closed mstanton1 closed 3 years ago

mstanton1 commented 3 years ago

Description

Edit slide deck for API Info Session on April 22nd.

  1. Initial slide deck showed pro-data as a different type of account. Update to make it clear that API users choose a premium account.
  2. Edit slides 12-16 as needed.
  3. Include slide on steps to obtain key.
  4. Include details on best practices, how to know if I'm an API user, and what to do if issues arise.

https://docs.google.com/presentation/d/1PoKY8j-U0SQ1Q3w-gmt7I5-kOR77Zmygt1yoE99VRU4/edit#slide=id.gcee66867c3_0_6

Tasks

mstanton1 commented 3 years ago

Edits completed on slide 12-16. @jyoti3286 can you review and advise if changes are required.

A few things to focus on 1) Slide 14 lists the details needed in the email request for an API key. Is there anything else you are aware we need? 2) Slide 16 covers the question Thor raised about deactivation of a key. Currently we can do this during business hours or the client can take their site down. We could give the ability for an end user to deactivate their key and Sumesh noted:

"The endpoint is there, I need to add some authorization to it. Also need to update the spec. not a biggie, but I would vote for building this on UI, if it’s a pressing requirement. all the endpoints are there and UI design as well"

@trishreimer I've listed SBC IT Operations Support as the group to receive the request for API access, as well as requests the deactivate an API Key. Do you agree with this approach?

trishreimer commented 3 years ago

@mstanton1 My understanding (which could be wrong) was that SBC IT Ops is a 'Service Desk', and the role of a service desk (in ITIL) is to be the point of contact for internal work between IT teams/our team and the business. I realize they support BN partners and OS partners but they don't necessarily support clients (end-users) per se. Since the API's will be accessed by external users/clients, I think the standard process from a support perspective would be for these clients to go to a 'help desk'. As you are aware, our 'help desks' are at capacity and stretched, and for Maximus - there's a contract piece we'd need to consider. But maybe worth exploring?? If IT Ops was the first point of contact, it would probably be the easiest as they could simply create a ticket and send to the product team. One issue is that they don't provide after hours support. Another approach is to setup an 'Ops' mailbox and dist list that includes key resources from the product teams and use this as the tier 1 for API support (and maybe ops tickets too). Maybe for now, we leave this out of the deck until we figure it out. People can email the engagement mailbox or reach out in other ways if they want support or have questions.

For next steps, I could create an OCM - API Epic and link this ticket and maybe create a new one to define the support process. Thoughts? @jyoti3286

mstanton1 commented 3 years ago

@trishreimer thanks for the feedback. Maybe we can turn to the PO's in tomorrows touch point meeting and set up a separate meeting if needed?

My thought with IT Ops is although it doesn't follow the true ITIL flow currently we don't have a way for an end user to shut off their key through the system. If we launch without a system function for turning off a key we'd need an option for an end user to reach us FAST if they required a key to be shut off during business hours. Are we confident that emails are triaged quickly and escalated accordingly through other help desks? As far as account set up, ideally we'd want to give API users one contact for all streams so whoever was capable of handling turning off keys would also ideally receive emails for account set up.

I don't think volume would be high which is a consideration. Similarly, the issue with keys too could be resolved if POs were able to fit in building out functionality so clients could turn off a key themselves. In that case speed for processing requests through us wouldn't be as critical.

trishreimer commented 3 years ago

okay. Let's discuss tomorrow. I don't think they are triaged quickly on any help desk or service desk because of the sheer volume of calls and tickets, which is why maybe an ops email to the project team may be best - skip the help desk and service desk all together.

mstanton1 commented 3 years ago

As per 7060 and a separate discussion with Kaine I've updated the contact for account set up to be BCRegistries@gov.bc.ca. I've removed reference to what to do if you need your key turned off (and noted this in the speaking notes) as PO's and stakeholders will need to determine if adding this feature in the UI should be done in the next PI. Tickets 7070 and 7071 have been created.