 |
 |
We did that all the time at the place we used to work. The business manager sets up things with a generic email and her contact whatnot as required, payment is made using the procurement card. In case of changes, you update the contact person, but the email and account info are otherwise left alone. In the case of AWS where you might want to bill things very separately depending on what it's used for, you set up different accounts for various departments, grants or whatever, and have it all paid through their consolidated billing. That way there's only one bill but it's clear which accounts charges need to be applied against. kyle On Mon, Mar 4, 2013 at 10:20 AM, Laura Robbins <[log in to unmask]> wrote: > We have a shared email account that we use for these situations. As > well, we have a master account/password list for all of the different > accounts that get created that is in a shared network folder. That > way if someone is out sick or on sabbatical, the information is > available to all of our full-time librarians. > > Laura Pope Robbins > Associate Professor/Reference Librarian > Dowling College Library > > Phone: 631.244.5023 > Fax: 631.244.3374 > > "A mind needs books as a sword needs a whetstone, if it is to keep its > edge." --Tyrion Lannister in A Game of Thrones by George R.R. Martin > > On Mar 4, 2013, at 11:11 AM, Jonathan Rochkind <[log in to unmask]> wrote: > > > Whether it's Amazon AWS, or Yahoo BOSS, or JournalTOCs, or almost > anything else -- there are a variety of API's that library software wants > to use, which require registering an account to use. > > > > They may or may not be free, sometimes they require a credit card > attached too. > > > > Most of them assume that an individual person is creating an account, > the account will be in that individual's name, with an email address, etc. > > > > This isn't quite right for a business or organization, like the library, > right? What if that person leaves the organization? But all this existing > software is using API keys attached to 'their' account? Or what if the > person doesn't leave, but responsibilities for monitoring emails from the > vendor (sent to that account) change? And even worse if there's an > institutional credit card attached to that account. > > > > I am interested in hearing solutions or approaches that people have > ACTUALLY tried to deal with this problem, and how well they have worked. > > > > I am NOT particularly interested in "Well, you could try X or Y"; I can > think of a bunch of things I _could_ try myself, each with their potential > strengths and weaknesses. I am interested in hearing about what people > actually HAVE tried or done, and how well it has worked. > > > > Has anyone found a way to deal with this issue, other than having each > API registered to an account belonging to whatever individual staff > happened to be dealing with it that day? > > > > Thanks for any advice. >