Several processes are available to trigger requests for creating new profiles and for adding accounts to user profiles. The same processes can also drive deactivations and changes.
A change may be detected in a system of record, such as an HR system or student enrollment system. This may trigger creation of a new user profile and/or one or more accounts on target systems.
Users may fill in access request forms on behalf of themselves (i.e., self-service) or of others (i.e., delegated). Where delegation is used, rules control who can request what on whose behalf.
An inbound web services API allows other systems, with suitable connection credentials and access rights, to request creation of user profiles or addition of new accounts.
A batch load mechanism is provided, essentially to submit a series of request forms, much like in the UI, but on behalf of rows in a data file (e.g., one request per row in a CSV file). This is a useful mechanism for near-real-time provisioning, as a trigger in an SoR can populate a small table of change events, which can be scanned every few minutes for work.
Changes to a role definition, combined with RBAC enforcement may trigger auto-submitted requests for changes to user access. Similarly, changes to the roles assigned to a user, via any of the above mechanisms, may also trigger creation of a user profile or changes to user access.
Regardless of the triggering event, all requests are subject to the same input validation, reformatting, attribute calculation, automatic resource assignment, approvals, audit logs, etc. These policies span request types.