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.