...
Requirement | Status | Use cases | ||||||
---|---|---|---|---|---|---|---|---|
Allow Organization record to be shared at the consortia level |
| Organizations generally have data that is universal and some that is specific to their relationship with a given library. Like Contact people. | ||||||
Allow contact people to be assigned locally to shared vendor records. These contact people should only be visible when viewing the organization in the tenant in which the contact people were created |
| Individual libraries or departments may deal with specific people/representatives of the organization. In consortia there is confusion around who's contact is who’s. The list of contacts being shared is even an issues because you need to differentiated the actual contact records from one another. | ||||||
| Individual libraries or departments will have specific Privileged donor information regarding their dealings with a given organization Same issue as above regarding donor information | |||||||
Allow notes to be assigned locally to shared vendor records. These notes should only be visible when viewing the organization in the tenant in which the contact people were created |
| Individual libraries or departments will have specific notes regarding their dealings with a given organization. Library specific notes. Eg, “really liked working with so and so”, remember to pay X, Had trouble dealing with X. Ideally these are shown only to members of library as they are very specific to that library. Not necessary a security/privacy risk. These may even confuse other libraries that deal with different people etc. These would also be much more useful if searchable | ||||||
| Individual libraries or departments will have specific Integration details Interfaces regarding their dealings with a given organization. Generally libraries have their own credentials for interfaces so currently sharing interfaces is problematic. However when each library creates their own it becomes difficult to identify who’s is who’s in the list of interfaces. | |||||||
| Individual libraries or departments will have specific Interfaces Integration details regarding their dealings with a given organization. Some libraries have different integration for different orders AND for different sub-libraries as well. | |||||||
| Individual libraries or departments will have specific Account numbers regarding their dealings with a given organization. Shipping and Billing addresses as well as account numbers must be unique. If not it is possible for parts of the workflow to confuse orders for different libraries. Payment method could be different between different libraries in a system even for the same vendor. One might use physical check and the other ACH (Automated Clearing House) Each institution has unique accounting codes. | |||||||
| Individual libraries or departments will have specific Privileged donor information Vendor terms regarding their dealings with a given organization IT’s possible that libraries will have different discount rates and these discounts should not be disclosed to other institutions. |
Existing Accordions for Reference
Summary
Notes
Contact information
Contact people
Privileged Donor information
Interface
Vendor information
Vendor terms
Integration details
Accounts
Proposed workflow:
Questions:
Question | Status | Conclusion | Comments | ||||||
---|---|---|---|---|---|---|---|---|---|
Should local data be visible to other member libraries at all? Say you add a note, are there situations where you would want other libraries to be able to see that. |
| ||||||||
Are there specific fields in Summary, Vendor information, vendor terms accordion that should actually be localizable? |
| Yes certain things should not be disclosed like Discounts in vendor terms |
Functionality Potentially Impacted by Changes:
...