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.
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.