Purpose
It's often necessary to carry out an action on a large number of accounts or user objects simultaneously. Many APIs only support a single object per transaction, and for several thousand transactions, this can take a very long time.
This group is gathering requirements for API calls that support bulk transactions that can change multiple user objects in a single transaction. These requirements will serve as input to the TIER API working group as well as material for the Provisioning Best Practices end product.
Use Cases for Bulk API Transactions
- On-boarding of batches of new students and other user types
- De-provisioning of graduated or separated students
- Provisioning large populations into a new service or target system.
- Data reconciliation between upstream and target systems
- Support for bulk-load tools such as for guest accounts for conferences
- Bulk credential locking as a result of phishing or compromised account
- Bulk change of entitlements or permissions due to a change in policy.
- Bulk change of entitlements or permissions due to roles ( IT, Functional or Business roles) re-assignments.
- Bulk change due to attestation of accounts/entitlements.
- Bulk query of directory attributes: I have a list of ID numbers that I need to turn into netID, name and email
TIER API Group Comments:
- Is identifying your targets and payload ahead of time, and then making individual calls not sufficient?
- Transactions, in the commit/rollback sense, are a useful construct when issuing a "bulk" operation. But bulk operations without additional transaction semantics are effectively just fire-and-forget collections of individual operations, so what's the value-add of a non-transactional bulk API over a one-at-a-time API?
- Do we define bulk operations as the same operation applied to multiple targets (e.g. add this person to many groups), or the same operation applied to one target with different payloads (e.g. for this group, add many people), or any collection of many operations that are prepared together?