Hello everyone,
We are starting to create PAPI credentials for internal use as well as third-party vendors. I am curious what other customers view as ‘best practices’ when setting up credentials. We will need to differentiate the transactions based on who performed the action.
I’m inclined to create one Workstation designated for PAPI use that all third parties can use with their PAPI calls. I will also create a new staff member for each new vendor with permissions based on what actions they will be performing. For internal PAPI use I plan to use the same Workstation described above as well as a unique user.
I would love to know thoughts on whether this approach mirrors your own approach to tracking the different transactions that are made with PAPI.
I will, of course, be creating new PAPI Keys for each vendor but to my knowledge, those aren’t tied to any privilege, correct?
I’m interested to see what other Polaris libraries have to say as well. We just switched from SirsiDynix Symphony to Polaris and had a setup similar to what you are describing in Symphony. So far, we have not created separate workstations, but we have created a unique staff member login for the PAPI credentials we have created for vendors. As far as I know, PAPI has no permissions.
I’m not the one who does the actual PAPI key management, but I’ll do my best based on having just gone through this with MessageBee to export our Polaris notices. Some PAPI calls are “public” and can be done with just the API key, others are restricted to staff access and require both an API key and a staff account for the vendor. UMS needed their staff account to have admin level permissions because they are writing back to the notification history. In general, we’re trying to follow the principle of least permissions and get really clear information from the vendor specifically which PAPI calls they’re going to make and only permission to that level.
We also created a workstation specifically for that vendor - in the past having a specific workstation ID tied to a specific source helped with troubleshooting as the workstation ID is accessible and searchable via SQL in the staff client.
Hi Amy,
Thank you for your insights. Our implementation consultant from III mentioned that a unique workstation for each vendor is not necessary. However, when you mention that having a specific workstation IDs tied to each source helps with troubleshooting makes me more inclined to follow your process. I think we will start out going that route.
Thanks for your time!
Aaron
There are also some canned and simplyreports reports that you can run by workstation, so having a separate workstation also makes those work out a little easier.
I would note that you might have to be deliberate with vendors that use PAPI about using your custom workstation id, I’m sure that many would just default to workstation id #1 because it is there on all systems, they might not even be aware that is something that can be specified when making the API calls.