Quick Add Subscriber Provisioning Workflow Structure ---------------------------------------------------- The Quick Add Subscriber (QAS) feature 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 QAS Bulk Loader sheet * The attributes supported by the API endpoint (``view/QuickSubscriber``) This View schema represents a simplified version of all possible Subscriber fields. Associated with the View is a Provisioning Workflow (PWF) called ``AddQuickSubscriber`` that captures these simplified fields and combines or maps them into the various components (services) of a full Subscriber. 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``, that separates out the data for each Subscriber 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 Config Templates of the selected Quick Add Group (QAG) is evaluated. |QAS-flow-img| Since the Quick Add Group Config Templates (CFTs) are evaluated inside the ``AddSubscriberNew`` workflow, it is important that the Subscriber Relation field names *not* be those of the QAS 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 QAS View and the Subscriber Relation schemas, for example ``username`` as opposed to ``userid``. The difference is subtle, but very important: the Subscriber user name in the QAS workflow context (``AddQuickSubscriber``) is ``username``, but in the Subscriber Relation workflow context (``AddSubscriberNew``) it is ``userid``. .. |VOSS Automate| replace:: VOSS Automate .. |Unified CM| replace:: Unified CM .. |QAS-flow-img| image:: /src/images/QAS-flow.png