!!! Overview[1]
The [{$pagename}] process is intended to help organizations more securely manage information about users on multiple systems and [applications]. 

All Organizations perform [{$pagename}] either manually or automated and most have some combination of both.

[{$pagename}] is typically associated within the an [Identity Management Architecture].

[{$pagename}] is handled within the [Identity Lifecycle Management]

In the complex [Regulatory Environment|IDM Related Compliance Items] [Provisioning Auditing] must be implemented within [{$pagename}].!! Goals of [{$pagename}]
To begin with, a discussion on the goal of [{$pagename}]. Typically, the term [{$pagename}] to encompass a large set of functions. Sometimes, these functions are also collectively referred to as [User Management]. 

The set of functions under the [{$pagename}] ‘umbrella’, then, are easily described with the acronym [CRUD]. If you’re familiar with database management, this acronym will be familiar as referencing the common database operations of [Create], [Read], [Update], and [Delete]. When we borrow the acronym for [{$pagename}], however, there is a slight modification:
* Create: Create fresh users in the downstream [application] or directory based on values derived from the a user Profile and [Claims] (think Group assignments). 
* Read: Import users from the downstream application or directory in order to match them to existing users, or to create new users from the imported application or directory users. 
* Update: For an application or directory user that is affiliated with or ‘tied to’ an user, update the downstream user’s attributes when the user is updated.
* Deprovision (not typically a Delete): ‘Deprovision’ the application user from the downstream application. This can take many forms; user disabled, user access permissions changed, user license pulled, etc. Confirm specific functionality on an app by app basis. 

But, most [Mobile Apps] and [WEB] [Application] do not require a user to be provisioned to the WEB Application. Typically, the WEB Application, only needs some assurance that the user is has [Authenticated]. The [OpenID Connect Provider] provides a “sub” [claim] which is guaranteed to be Unique for that Provider. The [WEB] [Application] can use the "provider-sub" combination as a identifier so that when that same user returns to the [WEB] [Application], the user can be identified.

Further, if an Organization desires central control of the user’s ability to Authenticate and/or of permission assignment, using OpenID Connect provides this ability without performing User Provisioning.!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [User provisioning software|Wikipedia:User_provisioning_software|target='_blank'] - based on data observed:2015-05-18