Quick add user provisioning workflow structure
--------------------------------------------------------------

The Quick Add User functionality uses a ``view`` model to define its schema that also ultimately defines:

* The form fields a user sees in the GUI
* The column headings in the Quick Add User bulk loader sheet
* The attributes supported by the API endpoint (``view/QuickSubscriber``)

This ``view`` schema represents a simplified version of all possible
user fields. 

Associated with the view is a Provisioning Workflow (PWF) called
``AddQuickSubscriber``, which captures these simplified fields and
combines or maps them into the various components (services) of a
full user. The main purpose of this workflow is to execute
an "Add ``relation/Subscriber``" operation.

The "Add ``relation/Subscriber``" operation in turn executes a *second*
PWF called ``AddSubscriberNew``, which separates
out the data for each user component or service and executes
an "Add" operation on the corresponding device models, for example
on ``device/cucm/Phone``.

It is inside this ``AddSubscriberNew`` workflow that the configuration templates 
of the selected Quick Add Group is evaluated.

|QAS-flow-img|

Since the Quick Add Group configuration templates (CFTs) are evaluated inside
the ``AddSubscriberNew`` workflow, it is important that the user ``relation`` field names *not* 
be those of the Quick Add User view. Generally, all field values
are made available to an executing PWF and is referred to as the *context*.

For example, refer to the diagram and notice the difference in field (attribute)
naming between the Quick Add User view and the user ``relation`` schemas, for
example ``username`` as opposed to ``userid``. The difference is subtle,
but very important: the user name in the Quick Add User workflow context
(``AddQuickSubscriber``) is ``username``, but in the user ``relation`` workflow context 
(``AddSubscriberNew``) it is ``userid``.


.. |QAS-flow-img| image:: /src/images/QAS-flow.png