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.

  • SoR-driven change

    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.

  • User entered request form

    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.

  • API access

    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.

  • Batch load

    A batch load mechanism is provided, essentially to submit a series of request forms, just like using the request portal, 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.

  • Role changes

    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.