356
     Run Schedule Section → Verify the status of latest run.
How to Trigger Batch NBA Case
Generally ,In production environment, there is a Scheduler configuration to run the cases daily at particular time and these checks are
typically done by L2Support Team whereas in development environments, we trigger the Cases manually and do the checks manually. We
use an activity rule to trigger the Case. when we run this custom activity, it will internally run the case. Below are the steps to trigger the
case using an activity rule .(Activity : CaseIgnitor)
1. Go to application.
2. Search for the CaseIgnitor activity and open the activity from VFUK-FW-AOMFW-Work-BatchNBA class.
3.  Go To Actions Menu and Click on Run.


357
4. Wait for the successful message as shown below.


358
Checks during/after the Case execution
 1. Check if the Case is Progressing and check logs in the Audit section:
  1. Open the Case from the case id/Work Item and Check the status of the Case.
2. There are 3 stages involved in Case Execution.
  1. Setup     2.Process   3. End
After the completion,each will be changed to green color with Tick mark.
3. You can check the Audit to see how the case is progressing.


359
4. We can check the log in the Audit Section.
2. Check the Status of Data flows which are Configured to run during the Case :
  1.  Navigate to Data Flow landing page and verify the Data flows are running are not.


360
If you want to see the Progress of the data flow visually, Click on the Data flow work Item id (DF-24695).


361
If there is any failure in the data flow, Then resolve the issue and Re-run the case.
3. Verify the Output of Batch NBA Case:
Once the Case execution is completed, Verify the Output of Batch NBA in the  BestOBtreatmentsByBatch Data Set.
1. Open the Data set, Go To Actions → Run
2. Browse the Data Set and click on Run.
By default it will show 50 Records,If you want you can increase the number in the text box.
1. If you want to see the Output of a single Known Customer,you can select Browse by keys operation and Provide the customer Id,
then click on Run.
2. If you want to delete the entire data from Data Set, then Select Truncate Operation.
3. If you want to delete one record from Data set using Customer ID ,Then select Delete-By-Keys Operation.


362
3.Verify the Output in the Clipboard page.
Browse-By-Keys :


364
Batch Extractor Case Testing : How-To
Introduction to Batch Extractor
Checks before Extractor Case Run
How To Trigger Batch Extractor Case
Checks after Extractor Case Run
Introduction to Batch Extractor
The Extractor Case is common across all other functionalities.(Ex:T2S,MVP,Batch). We differentiate the Extractor based on the Input
Parameter i:e (Extractor Type). The below Data flows are involved in Batch Extractor Case.
1. PrepareForOBProcessForBatch :  It reads the data from BestOBTreatmentsByBatch(Output of Batch   NBA Case) and writes to a
BestOBTreatmentsBeforeDedupe data set.
2. PopulateMasterDataSets : It reads the data from BestOBTreatmentsBeforeDedupe  data set and writes to 3 different destinations.
             1. ContactDetailMaster data set.
             2. PopulateTreatmentsForOB data flow : It executes the volume constraints strategy and populates
              volume limit for each treatment and writes to TreatmentsForOB Data set,which is used by Volume
            constraints activity.
            3. PopulateOffersBySubChannelForOB Data-flow :  It populates Sub channels for each Treatment
                using PopulateSubChannelBasedOffers Strategy and writes
                 OB CC treatments to OffersBySubChannelForOutboundCC Data set and
                 DM treatments to OffersBySubChannelForDirectMail data set.
   3. DedupeByContactDetail : It reads the data from ContactDetailMaster data set and
          BestOBTreatmentsBeforeDedupe data sets, and executes De-dupe the customer based on
          Contact Details and writes the output to BestOBTreatmentsAfterDedupe


Contact Details and writes the output to BestOBTreatmentsAfterDedupe
   4. ApplyVolumeConstraints : This Data flow is being called from an activity and it splits the customers
          based on the Volume limit and writes the output to VolumeConstrainedData data set.
   5. AugmentVolumeConstrainedData : It reads the data from VolumeConstrainedData,
      BestOBTreatmentsAfterDedupe data sets and writes to  BestOBTreatmentsAsTarget and
      BestOBTreatmentsAsControl Datasets based on the PotentialControlFlag value.
 6. ProcessBestOBTreatmentsAsTarget : It reads the data from BestOBTreatmentsAsTarget data set and
     Writes to different destinations as shown below.
         1.Process Outbound Data flow : It populates below datasets.
                 1.BestOutboundCCTreatmentsAfterControlGroups,
                 2. BestEmailTreatmentsAfterControlGroups,
                 3.BestSMSTreatmentsAfterControlGroups,
                4. BestAppPushTreatmentsAfterControlGroups,


365
                5. BestDirectMailTreatmentsAfterControlGroups
        2. Interaction History data set.
        3. SubscriprionsForOB Data set.
        4. WriteBatchDecisionOutput data flow.
        5. PopulateSeedTestLiveData data flow.
7. ProcessBestOBTreatmentsAsControl : It reads the data from BestOBTreatmentsAsControl data set and
 ProcessNonChildBestOBTreatmentsAsControl data flow, ProcessNonChildBestOBTreatmentsAsControl.
8. SetSubscriptionCampaignFlags :  It reads data from SubscriprionsForOB data set ,      BestEmailTreatmentsAfterControlGroups
data set , BestSMSTreatmentsAfterControlGroups data set and sets EmailEligibleFlag, SMSEligibleFlag values and writes to
SubscriptionCampaignFlags Database table.
Checks before Extractor Case Run
1.Check if the previous case status is Resolved-completed/Resolved-Cancelled :
      1. Go to App Explorer and Search with VFUK-FW-AOMFW-Work-Extractor class name, click on the class record as shown below. It will
open all instances of the class. (Here Instances = Case work Items).
  2. Open the latest work item /Case. ( Sort work Items based on 'Updated on' date).


366
3. If the status is not Resolved-Competed/Resolved-Cancelled, Then Update the status to Resolved- Completed/Resolved-Cancelled.
   Go To Actions → Change Stage → Select End stage → End/Abort .
2. Check Batch NBA Extractor Case configurations : We can see the Batch NBA Case configurations here.
  Case ID : ID of the current Running case/ last case.
  Case Status : Status of the current case/ last case. If the case is running the status changes to Running or if the case is completed, then
status changes to Completed.
  Case Dependencies: If the dependent Cases which are configured in the Case dependency field are running,Then the Extractor case will
not start until the Dependent cases are completed.
Go To Data explorer → AOM Config Data Type →  (Config Name=BatchNBAExtractor) .
If Case is Stuck/Unable to change the status of the Case from Work Item then we can quickly update the Case status value to
Completed and do another run.


367
3. Check if the previous Email and SMS Campaign runs were successful:
If there is a failure in previous Email and SMS Campaign runs,Then that should be resolved before triggering the next Extractor case. To
verify the Campaign Status:
Switch to Pega Marketing Portal → Campaigns → Open Email Campaign/SMS Campaign → Go to
Run Schedule Section → Verify the status of latest run.
How To Trigger Batch Extractor Case
Generally ,In production environment, there is a scheduler configuration to run the cases daily at particular time and these Checks are
typically done by L2Support Team whereas in development environments, we trigger the Cases manually and do the checks manually. We
use an activity rule to trigger the Case. When we run this custom activity, it will internally run the case. Below are the steps to trigger the
case using an activity rule .(Activity : CaseIgnitor)
1. Switch to AOM V3 application (AOM:Market Admins access group).
2. Search for the CaseIgnitor activity and open the activity from VFUK-FW-AOMFW-Work-Extractor class.
 3. Go To Actions Menu and Click on Run.


368
4. Select CasesubType Value and Click on Run.
5. Wait for the success message as shown below.


369

Checks after Extractor Case Run
1. Check if the Case is Progressing and check logs in the Audit section:
   1. Open the Case from the case id/Work Item and verify the status of the Case.
2 . There are 5 stages involved in Case Execution.
1. Setup  2.Prepare  3.Extract 4.Package 5. End
After the completion of each stage,it will be changed to green color with Tick mark as below.


370
3. We can check the Audit to see how the case is progressing.


371
2 . Check the Status of Data flows which are Configured to run during the Case :
1. Navigate to Data Flow landing page and verify the Data flows are running are not.


372
If you want to see the Progress of the data flow visually, Click on the Data flow work Item id (DF-24695).
If there is any failure in the data flow, Then resolve the issue and Re-run the case.
3. Verify the Output of Batch NBA Extractor Case:
Once the Case execution is completed, We can verify the Output at multiple places based on the channel.
Email : 1. Verify whether the Email Campaign run is completed and it emits any offers are not.
            2. Verify the Interaction History in Database.
SMS :  1. Verify whether the SMS Campaign run is completed and it emits any offers are not.
            2. Verify the Interaction History in Database.
OBCC : 1.The Output of OB CC channel will be written to an Output file,which gets generated when
               the Extractor case reaches to Extract Stage. Please refer OB CC Output file for more details.
            2. Verify the Interaction History in Database.
DM : 1. The Output of DM channel will be written to an Output file,which gets generated when the


373
          Extractor case reaches to Extract Stage. Please refer DM Output File for more details.
          2. Verify the Interaction History in Database.


374
IVR - How To
O v e r v i e w
IVR channel is integrated with AOM through GetNBA data flow to generate an eligible offer and related routing option for customers
interacting with IVR.


375
IVR Subchannels and Respective Request Structure/Data
XXXXXXXXXXThere are two subchannels for IVR channel:
1- PreNLCS: This flow runs initially when the customer first interacts with IVR, so at this point, there isn’t any stated purpose yet and intent
is identified based on the rules using past interactions of the customer.
Request Parameters:
              - SubChannel = “PreNLCS”.
              - Service number is required.
              - Primary context is always empty.
Sample Request:

2- PostNLCS: This flow runs when the customer stated a purpose (e.g. problem-sim) on IVR. So their intent is identified based on this
purpose which is also named apptag.
Request Parameters:
              - SubChannel = “PostNLCS”.
              - Service number is required.
              - Primary context (apptag) is required.
Sample Request:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24{
  "Identifier": {
    "Account": {
    "AccountNumber": "XXXXXXXXXX",
    "Status": "Existing",
    "Type": "Consumer"
    },
    "ServiceNumber": "XXXXXXXXXX"
  },
  "RequestorDetail": {
    "Channel": "IVR",
    "SubChannel": "PreNLCS"
  },
  "Context": {
   "PrimaryContext": "",
    "NoOfActions": 1,
     "Detail": [
     {
      "Name": "ConnectionId",


"Detail": [
     {
      "Name": "ConnectionId",
      "Value": "CON_28474_847464"
      }
    ]
  }
}
1
2
3
4{
  "Identifier": {
    "Account": {
    "AccountNumber": "XXXXXXXXXX",


376

5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24    "Status": "Existing",
    "Type": "Consumer"
    },
    "ServiceNumber": "XXXXXXXXXX"
  },
  "RequestorDetail": {
    "Channel": "IVR",
    "SubChannel": "PostNLCS"
  },
  "Context": {
   "PrimaryContext": "problem-sim",
    "NoOfActions": 1,
     "Detail": [
     {
      "Name": "ConnectionId",
      "Value": "CON_28474_847464"
      }
    ]
  }
}


377
Configuring Apptag Data
When a customer states a purpose on the IVR, this purpose is converted into an apptag. Each apptag has its own specific configurations
(Event Parameters) that are stored in AOMBusinessData data type. This configuration data is used to populate tokens that are used to
generate service request parameters and SMS content further in the flow. These apptag parameters are listed in the table below and for a
new apptag, they should be configured on the PM Tool.

Configuring a New Apptag in PM Tool
To configure the apptag parameters refer to steps under Business Config heading in Other Screens page.   Apptag Number ID of the apptag in IVR sytem
Default Routing Option Shows which routing option is the default. (IVR Treatment Code)
Default Deflection Type Soft / Hard
Online URL URL that will be populated in SMS Text when the treatment variant is Online
Webchat URL URL that will be populated in SMS Text when the treatment variant is Webchat
Tobi URL URL that will be populated in SMS Text when the treatment variant is Tobi
Call Reason Text to be populated in SMS Text
Apptag Text Text to be populated in SMS TextParameter Description


378
Identify Intent for Each Subchannel
Intents are identified based on customer events coming from different sources. These events are mapped to intents according to the
mapping in EventToIntent decision data. This mapping is used in the strategies to identify customer intents and calculate intent’s confidence
score. EventDataSource column shows the source of the related event.
Configuring EventToIntent Mapping
Step 1: When a new apptag is added, it should be mapped to its related intent too. If the new apptag is mapped to a new intent, first the
intent should be created and mapped to an offer and business purposes if required.  To configure the intents refer to steps in intent related
screens page.
Step 2: Map the new apptag to the related intent. To configure event to intent mapping for apptags and Tealium events refer to steps in
Event page.
Identifying Intents
Intents are identified in two different ways:
1. Based on the rules (EventDataSource = IH/Tealium/EventStore).
2. Based on the call context (EventDataSource = Context).
The resulting intents are populated into the CustomerIntentList property and offers are identified based on these intents through the
GetNBA funnel.
Data Flow: IdentifyCustomerIntentsRealTime
Strategy: EvaluateCustomerIntents
1- Identifying Intents for PreNLCS SubChannel (Rule Based Approach)
Since PreNLCS doesn’t have a primary context, intents for PreNLCS are identified based on the rules using past events, interactions,
webpage visits of the customer that occurred in the last X hours. X is defined on the EventRecency property of EventToIntent DD and the
confidence score of the intent will decrease gradually depending on this value and the time passed over the interaction.


confidence score of the intent will decrease gradually depending on this value and the time passed over the interaction.
There are three groups of this approach according to event source:
EventStore: (EventDataSource = EventStore)
Strategy: ValidateIntentsWithEvents


379
Interaction History: All communications with the customer including offers sent and customer responses are stored in the interaction
history. (EventDataSource = IH)
Strategy: ValidateIntentsWithIH
Tealium: Customer’s website page visits are stored as events. (EventDataSource = Tealium)
Strategy: ValidateIntentsWithTealium
Strategy: IdentifyRecentEventBasedIntents
2- Identifying Intents for PostNLCS (Real Time Event Based Approach)
Intents for PostNLCS are identified based on the call context. The apptag (primary context) stated by the customer (e.g. problem-sim) is
used to identify the intent (e.g. Help-Device) based on the mapping in EventToIntent DD (EventDataSource = Context)
Strategy: IdentifyRTEventBasedIntents
If the apptag is not configured in the EventToIntent mapping, the strategy will generate "Primary context not Configured" error message.


380
Configuring Offers
Standard NBA funnel step is executed to identify eligible offers for IVR.
For PostNLCS there is only a single offer:
If an existing offer is required to used for PreNLCS, its Execution Mode can be updated to include GetNBA. PreNLCS Offers:
Configuring Offers in PM Tool
To create a new offer refer to steps in Offer Related Screens. Service RedirectCall GetNBABusiness Purpose Offer Name Offer Execution Mode
Upsell AddDataExtraRecurring GetNBA
Upsell AddInternationalMinutes GetNBA
Service Help GetNBA
Service SetSpendManagerLimit GetNBA
Retain ServiceMessage GetNBABusiness Purpose Offer Name Offer Execution Mode


381
Identify Offer/Business Purpose for a Given Intent
If there is an intent generated based on an apptag (stated intent), offers will only be identified based on this intent, and rule based intents
(inferred intent) will be omitted.
There are two ways to identify offers depending on the confidence score range of the intent:
If the confidence score range is high, offers are generated using the mapping in IntentToOffer decision data.

If the confidence score range is low, instead of offers, firstly business purpose is identified using the mapping in
IntentToBusinessPurpose decision data, then offers under this business purpose are generated.
The confidence score of the intent should be greater than or equal to 1 to be considered as an intent to generate offers from. Otherwise, the
intent will be discarded.
S t r a t e g i e s : AssignIntentToOfferOrBusinessPurpose, IdentifyOffersForEligibleIntents


382
Configuring Offer Variants
A new offer variant should be created if
A new SMS message template is needed for a specific apptag (Only for PostNLCS).
A new commercial offer content required.
A new IVR message is added.
To create a new offer variant refer to steps in Offer Variant.


383
Configuring Routing Options (Treatment Variants)
Treatment Variants
IVR routing options are defined as treatment variants.
IVR Treatment Code is the routing option code on the IVR and it should be configured for PostNLCS treatment variations.
Configuring Treatment Variants in PM Tool
If a new routing option is required, a new treatment variation should be created. To create a new treatment variant, refer to steps under
Treatment Variation heading in Treatment Variation page.
Treatment To Treatment Variations (TTV)
For IVR, the rank attribute on TTV is used to identify the best treatment variation for each treatment and it should be configured.
Eligibility rules can be defined for a TTV if it’s required.
For SMS treatments, SMS templates should be configured on T2TV. Dynamic parameters that are written between [] are populated by
using apptag parameters. (Refer to IVR -SMS and Populating SMS Data Tokens Using Apptag Data).


384
If a new SMS template is required, a new offer variant should be created.
Configuring Treatment To Treatment Variants in PM Tool
A new T2TV should be created if a new offer variant or a new treatment variant is created.  To create a new T2TV, refer to steps under
Treatment To Treatment Variations (TTV) heading in Treatment Variation page.

Output Properties Mapping (T2TV Actions and T2TV Attributes)
After the treatment variant is identified through the flow, parameters of the request (AOM Interface Spec - GetNBA) that will be sent to the
IVR, are populated according to the templates defined in T2TVAttributes and T2TVActions decision data.
Strategy: PopulateOutputPropertiesForGetNBA
T2TV Actions
Actions part of the service request defines what should be the action to take and generated based on the ActionDetail attribute of
T2TVActions decision data. For the example below, RecommendedRouting and DeflectionType are Action Attributes. If a new Action
Attribute is required, it should be configured on the PM Tool.
ActionList.Actions section of the response:

Configuring T2TV Actions in PM Tool
When a new T2TV is defined, TT2V Actions should be configured.  To configure T2TV Actions, refer to steps under T2TV Actions heading in
T2TV Actions and T2TV Attributes page.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17"Actions": [
  {
      "Type": "Routing",
      "Outcome": "Shown",
      "Id": "IVRSoftDeflection",
      "Detail": [
         {
            "Name": "RecommendedRouting",


"Detail": [
         {
            "Name": "RecommendedRouting",
            "Value": "agent"
        },
        {
            "Name": "DeflectionType",
            "Value": "Soft"
        }
     ]
    }
   ]


385
T2TV Attributes
Details part of the request defines the details of the action and generated based on the configuration in the TemplateDetails attribute of
T2TVAttributes decision data.
As a first step, values for dynamic parameters written between “[]” are populated:
- MessageId is the id of the message on IVR that the customer will be deflected. It’s a combination of Apptag number and IVR Treatment
Code (MessageID = "1"+ Apptag Number + IVR Treatment Code).
- AppTag parameter is populated with the apptag value that the customer stated.
- Reason parameter shows the reason for the deflection.
(Strategy: PopulateTokenValuesforApptag)
Then parameters replaced with these values (Strategy: SetIVRTokens).
Detail section of the response:

Configuring T2TV Attributes in PM Tool
When a new T2TV is defined, TT2V Attributes should be configured too. To configure T2TV Attributes, refer to steps under T2TV Attributes
heading in T2TV Actions and T2TV Attributes page.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15"Detail": [
     {
        "Value": "enquire-order",
        "Name": "AppTag"
     },
     {
         "Value": "10346",
         "Name": "MSG_ID"
     },
     {
          "Value": "enquire-order-no recent visit or deflection-Web",
          "Name": "Reason"
     }
   ]


386
Identifying Routing Option (Treatment Variants)
Standard NBA funnel step is executed to identify eligible treatment variants.
For IVR - PostNLCS,  to decide routing on Agent vs Tobi /Webchat / Online additional validations are applied.
Also to arbitrate between Tobi /Webchat / Online, IVR Routing BDC model or Apptag configuration is used.
Strategy: ApplyAdditionalTreatmentVariationValidations
Validating through IH and Tealium Interactions
It’s checked if the customer has any previous routing or Tealium interactions and if the rules below are met, the customer is routed to an
agent:

Strategy: IHandTealiumValidation

Validating through BDC Model
If the customer does not have any previous routing or Tealium interactions, IVR Model is queried to find if there is a recommended routing
for the subscription, and treatment variation is selected based on this value (IVR Treatment Code). If a recommended routing is not
available for the customer, default routing option is applied according to Apptag configuration.
Strategy: IdentifyTreatmentVariantByBDCModelTobi !Web Page Visit Rule
and
!Deflected with same AOM Intent
and
!Deflected with same AppTag IntentWebchat
OnlineTreatmentVariation Rule
Web Page Visit Rule Customer visited the URLs for AOM Intent in
last 24 hoursTealiumData
Deflected with same AOM Intent Customer deflected with same "AOM Intent "
in last 24 hoursIH
Deflected with same AppTag Intent Customer deflected with AppTag Intent in last
24 hoursIHRule Pattern Data Source
BDC Model is not available Select Single Treatment Variation according to EventParameters -
DefaultRoutingOption configuration for ApptagBDC Model is available Select Single Treatment Variation according to BDC model output


387
Validating Routing Recommendation
Some IVR routing options might have been disabled. In this case, these routing options are provided in the detail section of the service
request generated by IVR as “Disabled”. If recommended routing for treatment variant is one of these disabled routing options, it will be
discarded.
S t r a t e g y : ValidateRoutingRecommendation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31{
  "Identifier": {
    "ServiceNumber": "XXXXXXXXXX"
  },
  "RequestorDetail": {
    "Channel": "IVR",
    "SubChannel": "PreNLCS"
  },
  "Context": {
"NoOfActions": 1,
    "Detail": [
      {
        "Name": "ConnectionId",
        "Value": "CON_28474_847464"
      },
      {
        "Name": "international",
        "Value": "Disabled"
      },
      {
        "Name": "lost",
        "Value": "Disabled"
      },
      {
        "Name": "phone-sales",
        "Value": "Disabled"
      }
    ]
  }
}


388
IVR -SMS and Populating SMS Data Tokens Using Apptag Data
For Post NLCS, if the routing option is one of Tobi, Webchat, and Online, an additional SMS notification including the details of the call and
related URL is sent to the customer as well.
SMS template samples:
Content of the SMS message is generated dynamically using related apptag parameters (refer to Configuring Apptag Data). As a first step,
these data tokens are populated by using AOMBusinessConfig data. For the example below [TobiURL] and [CallReason] are used to
generate the SMS message.
Strategy: PopulateEventParameters
Then dynamic values in the SMS template (TreatmentDynamicVariable1) are replaced with these respective values to generate the final
SMS text.
Hello. Thanks for your call today. Head to [TobiURL] to [CallReason].


389

Strategy: SetSMSTokensForIVR


390
Elaborating End to End Run Using Postman
To see the steps for IVR testing refer to IVR End-To-End Testing page.


391
Assisted Upgrade: How-To


392
Get Recommendation API
Get Recommendation API call returns the top Recommendations for the customer in the context as part of the upgrade journey.
Pre-requisites
Most of the subscription/customer data is already populated by GetCustomer API call, before making get recommendations call barring a
few, which are added/composed in:
Data Flow: PrepareDataForGetRecommendation.
For watch subscriptions, PrimarySubscription attribute will be populated with the subscription data which is the primary subscription of the
watch subscription. To identify the primary subscription, PrimarySubscriptionId attribute will be used.
Customer intent is also evaluated by calling:
Data flow: IdentifyCustomerIntentsForGetRecommendation.
GetCustomer api call populates Data Set: SubscriptionXCAR. So the customer must be present in this data set for a successful
GetRecommendations API call.
Data coming from BDC Model is present in below two data sets, both added to Subscription data in .BDCRecommendationList in Data
flow: PrepareDataForGetRecommendation.
1. UniversalTariffRecommendation
  2. DeviceRecommendation
Above data sets are populated by BDC Loader.
 Sequence of Flow:
Rest API call with valid request.
Activity: GetRecommendations
Dataflow: GetAssistedUpgrade


393
Strategy: IdentifyBestInboundCCTreatmentsForSubscription – This strategy calls various  substrategies to get the eligible Offers,
Offervariants, Treatments,TreamentVariants and along with the recommendations for the customer. Logic returns individual SR pages
with pre-defined response types and positions along with relevant output attributes to be displayed on the UI.
Output: After hitting the GetRecommendations API, all the parent records will be stored in InteractionHistory &
InteractionHistoryReporting tables. Parent and child records will be stored in the RecommendationItems table.
To debug any issues while running the service, we added a new dataset DebugAssistedUpgrade to get the all the details if any issues
API Request
To hit the actual api call and to test the logic end to end, Soap UI software is used to send the request and get a response. (It’s upto the
developer’s to choose which software to use).
A sample API request will look like below
SecondaryContext= NBA
{
"AgentId":"Omni"
,"CaseId":"XXXXX"  → Service Number from subscription table
,"Channel":"InboundCC"
,"Division":"Webchat Saves"   → Division may vary with the customer
,"LoanEligibilityStatus":"ELIGIBLE" → Can be eligible or ineligible
,"OrderType":"Service"
,"OwnerAccountNumber":"XXXXX" → Account number from the subscription table
,"PrimaryContext":"Upgrade"
,"pxObjClass":"VFUK-VADR-Int-GR-RequestBody"
,"SecondaryContext":"NBA"
,"SubscriptionId":"XXXXX" → Customer
,"SubChannel":"VADR"
}
When SecondaryContext=RefineBy
{
"AgentId":"Omni"
,"CaseId":"XXXXX"  → Service Number from subscription table
,"Channel":"InboundCC"


,"Channel":"InboundCC"
 ,"Division":"Webchat Saves"   → Division may vary with the customer
 ,"LoanEligibilityStatus":"ELIGIBLE" → Can be eligible or ineligible
 ,"OrderType":"Service"
,"OwnerAccountNumber":"XXXXX" → Account number from the subscription table ,"PrimaryContext":"Upgrade"
,"pxObjClass":"VFUK-VADR-Int-GR-RequestBody"
,"SecondaryContext":"RefineBy”
 ,"SubscriptionId":"XXXXX" → Customer
 ,"SubChannel":"VADR"
 ,"HandsetManufacturer":"Apple"
  ,"HandsetModel":"Apple iPhone 6s Plus 64Gb space grey (Nearly New)"
 ,"Has5G":"True"
,"NearlyNew":"True"
 }
Watch Subscription - SecondaryContext= NBA
{
"AgentId":"Omni"
,"CaseId":"XXXXX"


394
,"Channel":"InboundCC"
,"Division":"Webchat Saves"
,"LoanEligibilityStatus":"ELIGIBLE"
,"OrderType":"Service"
,"OwnerAccountNumber":"XXXXX"
,"PrimaryContext":"Upgrade"
,"SecondaryContext":"NBA"
,"SubscriptionId":"XXXXX"
,"SubChannel":"VADR"
,"PrimarySubscriptionId": "XXXXX"
}
Watch Subscription - SecondaryContext=RefineBy
{
"AgentId":"Omni"
,"CaseId":"XXXXX"
,"Channel":"InboundCC"
,"Division":"Webchat Saves"
,"LoanEligibilityStatus":"ELIGIBLE"
,"OrderType":"Service"
,"OwnerAccountNumber":"XXXXX"
,"PrimaryContext":"Upgrade"
,"SecondaryContext":"RefineBy"
,"SubscriptionId":"XXXXX"
,"SubChannel":"VADR"
,"HandsetManufacturer":"Apple"
,"HandsetModel":"Apple Watch Series 5 40mm gold (Nearly New)"
,"Cost":"£300-£500"
,"SIMO":"False"
,"PrimarySubscriptionId": "XXXXX"
}
IdentifyEligibleIBCCTreatments
Provides the list of Eligible offers, offer variations and treatments for the customer.
o    Proposition Decision Data: Configure > Decisioning > Decisions > Proposition Management > Hierarchy > Renew) > Offers,
Offer Variations, InboundCC
o    Proposition Filters: Records > Decision > Proposition Filter > RenewOfferVariationsEligibility, RenewOffersEligibility,
RenewInboundCCTreatmentEligibility.
IdentifyTreatmentSubChannel
 Passes the above list as is because the Execution mode for InboundCC is NBAA.
IdentifyBestTreatmentforSubscription
Provides max offers and also applies parent-child treatment bundling.


IdentifyBestTreatmentforSubscription
Provides max offers and also applies parent-child treatment bundling.
o    Decision Data: Offer Decision Mix  , ParentChildTreatments
CalculateDeal
        Calculate the deal items.
IdentifyTreatmentVariations


395
Provide List of eligible treatment variations.
o    Proposition Decision Data: Configure > Decisioning > Decisions > Proposition Management > Hierarchy > Renew) >
TreatmentVariations, TreatmentToTreatmentVariations
o    Proposition Filters: Records > Decision > Proposition Filter > RenewTreatmentVariationsEligibility,
RenewTreatmentToTreatmentVariationEligibility
PopulateOutputPropertiesForIBCC
Generate RecItemID for each recommendation and lists the necessary output properties for the Get Recommendation API call.
SetIHPropertiesForAllChannels > SetIHforInboundCC:
Set the interaction history for the current request.
SetErrorMessage
Below error messages are set at the framework level.
If no result from IdentifyBestTreatmentforSubscription then “No Eligible Treatments”
If no result from CalculateDeal then “No Eligible Upgrade Deal”.
If NoRecommendation=” Yes”  then “No recommendation is available for the customer”.
If no result from SetIHPropertiesForAllChannels.pyName then “No Output Properties”.
Get Recommendations API Spec:
https://vodafone.sharepoint.com/:x:/r/sites/AoMProgramme/_layouts/15/Doc.aspx?sourcedoc=%7B35805FA9-38CE-4C30-8AD6-BADE
BEF7BAFF%7D&file=GetRecommendations.xlsx&action=default&mobileredirect=true -

Connect your OneDrive account


396
Identifying Best Deal
PickBestPathway: This strategy is used to pick the best pathway based on request parameters, Customer RE Type, BDC model, refineBy
parameters and model score details. We are importing ModelScoreList and calculate for the best pathway. The best pathway is calculated
for two different scenarios.
1. Is Watch Subscription
2. Secondary Context= NBA
3. Secondary Context = RefineBy
  Pathways:-
ToSIMO
ToSIMO30
ToHandset
ToWatch
PickBestTenure: This strategy is used to pick the best tenure based on the request parameters
SecondaryContext= NBA or RefineBy and TariffTenure.
CalculateUpgradeDeal: This strategy gets the customer current details like tariff, AddOns, Discounts and PreS15 calculations. (Refer for
more details: Customer Current Details ).
GetGlobalFixedProductConfiguration strategy used to get if any fixed products are enabled based on Team, Channel and OrderType.
Decision Data: GlobalFixedProductConfiguration (Screen will be added further).
 IdentifySegmentStrategyforSubscription strategy is used to identify segment strategy based on intents.
DataPage Import: CustomerIntentList
Decision Data: IntentToSegmentStrategy (For Configuring IntentToSegmentStrategy please refer to steps in the Segment Strategy screen
).
Identify the Recommendations (Logic/Commercial). The Commercial Recommendations take precedence over the Logic
Recommendations i.e., if there is a Commercial Recommendation in Position 1, the Logic recommendation will take Position 2 and 3. If
all the positions are filled by Commercial Recommendation, then Logic Recommendation strategy execution is skipped.
Commercial Recommendations are identified by providing both Customer current details and with all Eligible treatments from standard
NBA funnel
Strategy IdentifyCommercialRecommendations
With identified Eligible pathways and customer current Details identify all the Logical Recommendations.
    Strategy IdentifyLogicRecommendation


With identified Eligible pathways and customer current Details identify all the Logical Recommendations.
    Strategy IdentifyLogicRecommendation
If Pathway is “ToWatch” identify logic recommendation for Watch.
     Strategy IdentifyDeviceRecommendation
If error message “Out Of Stock” is set, then NoRecommendation and error message will be sent further.
Call sub-strategy DedupeSameRecommendations. As the name suggests, once we identify all 3 recommendations (combination of
Logic and Commercial), this strategy is then used to de-dupe recommendations to provide up-to 3 distinct recommendations.
 CalculateNetRevenue strategy will calculate the netRevenue for each RecommendationID during recommendation.
If there are no recommendations to the customer, setting the below properties and throwing an error message at the framework level
(No recommendation is available for the customer).
ModelDetails from the BDC Model.
ProductRecommendationType=”Tariff”


397
ToPathway
NoRecommendation =”Yes”
DataPage Importing: D_ServicesForTariff
Input:-
1. Tariff Identifier
  2. Division
 Note:-  The columns required from D_ServicesForT ariff to be configured in the AOM Config.


398
Customer Current Details
Customer Current Details
GetCustomerStarRating
·         Import the model score for the modelId=10 and set the customer star rating.
GetTeamForAgentDivision
·         Based on the customer division, the team and division will be fetched from the Decision Data DivisionToTeam. To configure/create
new refer the steps in Tool Division to Team mapping
GetCurrentTariff
·         Get GPSL Data(Product Root) from the request and fetch all the customer related details from the database. The product roots
required for to fetch the details are.
o     FulfilmentItemCode= Mobile Service
o    FulfilmentItemCode=Handset
·         Fetch the addon details from the GPSL and pc_account_service table. (Strategy:CalculateAddOnData).
·         Check if the customer has discount or not by importing GPSL data and SubscriptionInvoiceChargeList table (Strategy:
CalculateCustomerDiscountFlag).
·         Get the list of addons and the addon cost by fetching GPSL data and decision data NetMafAddonListConfig. (Strategy:
CalculateAddonCost).
Configuring NetMafAddonListConfig Please refer Addon Group Screen.
·         Fetch tariff discount details from GPSL and pc_discount table (Strategy CalculateTariffDiscount)
Decision Data: RangeMapping
                         TariffGroups
Configuring Range Mapping and Tariff Groups please refer Band Management and Tariff Groups screens
·         Calculates different PreS15Maf for the customer and select suitable PreS15Maf based on current Customer type (Strategy
CalculateS15MafandBand)


399
Configuring And Evaluating Commercial Recommendations
Configuring And Evaluating Commercial Recommendations
 IdentifyCommercialRecommendations
 To get the eligible recommendations, all the tariffs, discounts, Addons, handsets for recommendation id and recommendation position
are configured in the below decision data.
Decision Data: CommercialRecommendations
To create/configure new commercial recommendations refer steps in (Commercial Recommendations screen - Commercial
Recommendations )
 Commercial Recommendations that match with eligible pathways are returned. For example, if the eligible pathway is ToSIMO, SIMO
related commercial recommendations are returned.
 Evaluation of cohorts using CustomerCohorts decision data. To create a new customer cohort, refer to steps in (cohorts screen URL -
Cohorts Management )
Populate product details and check compatibility for each product. The product details included in this strategy are Tariff, Discount,
Addon/Service, Handset, AutoAddedAddOn / AutoAddedDiscount.
  Strategy: GetProductDetailAndEvaluateCompatibility
Validate the commercial recommendations eligible for Grow rule by fetching data from UpgradeLifeCycleS15RuleConfig decision data.
(Strategy: - CheckUpgradeLifeCycleS15Rule).
 If there are any handset products, populate stock details from the D_GetStockAvailability Data page. If the GSA service is successful
then stock details will be sent, if not handset will be dropped.(Strategy: GetStockDetails).
 Tariff PC_Tariff_v D_EligibleTariffsForDept EvaluateTariffVisibility
Addon PC_Acct_Service_v D_ServicesForTariff EvaluateServiceCompatibility
Discount PC_Discount_v D_DiscountsForTariff EvaluateDiscountVisibilityCompa
tibility
Handset PC_Paym_Handset_v D_EligibleHandsetsForTariff EvaluateHandsetCompatibility
AutoAddedAddOn  D_DiscountsForTariff GetPromotionalAddonsListDetail
s


AutoAddedAddOn  D_DiscountsForTariff GetPromotionalAddonsListDetail
s
AutoAddedDiscount  D_ServicesForTariff GetPromotionalDiscountsListDet
ailsProduct Type Set details from DB Data page used for evaluation Strategy used for compatibility


400
Configuring and Evaluating Logic Recommendations
Configuring and Evaluating Logic Recommendations
Identifying Logic Recommendation for Handset
GetRecommendedHandset
For secondary context NBA, get the devices from BDC model and get the sellable device from D_SellablePaymHandsetBySKU
datapage.
For RefineBy, get the recommended device from the list of devices from D_SellablePaymHandsets datapage prioritize based on
handset model, device storage, and device color.
Get the stock details from D_GetStockAvailability datapage. If stock is available then get the top device.
Set Error message “Out Of Stock”, if secondary context is “RefineBy”, max quantity=0 and quantity status=”Stock Details
Unavailable”/”Preorderable ”/”Backorderable”.
If error message is set then tariff and discounts will not get executed.
To configure devices in BDC, the customer should have the device under the model score 6.
Data page: D_SellablePaymHandsetBySKU
GetRecommendedTariff
The below decision data are used to configure recommended tariffs.
Decision Data: RecommendationBlocks
  S15Threshold – For S15ThresholdValue (refer steps to configure in PM Tool S15Threshold )
Get the eligible tariffs from the product catalogue (Strategy: GetListofActiveTariffs) and BDC models based on the customer current
information.
Data page: D_EligibleTariffsForDept (get list of eligible tariffs based on the division, channel and team of the customer).
Decision Data: TariffGroups – to get eligible tariff groups. (Refer steps to configure in PM Tool Tariff Groups )
To validate the recommendations blocks eligible for Grow rule configure in the decision data (UpgradeLifeCycleS15RuleConfig)
Tariff blocks are evaluated based on below table.


401
CalculateUpgradeDiscount
Identify if the recommended tariffs are with auto add-ons and discounts and recommended tariffs and discounts are fixed or not, if not
then get the discounts (Upsell, PriceMatrix, SegmentOf1).
Data page: D_DiscountsForTariff – For eligible auto discounts for the tariff
Decision Data:
1. AssistedUpgradeTeamDiscountConfig – Discount’s configuration refers steps in PM Tool.
2. AssistedUpgradeUpsellDiscountConfig – Upsell Discount Configuration (Refer steps in PM Tool Upsell Discount Config )
3. PriceMatrix - PriceMatrix Discount Configuration in PM Tool
4. SegmentOf1DiscountStrategy - SegmentOf1 Discount configuration in PM Tool Segment Of 1 Discount
Identifying Logic Recommendation for Watch
Tariff, Discount, and Device for watch subscriptions will be identified in IdentifyDeviceRecommendation strategy. There are three
substrategies called for each of these items:
GetRecommendedWatch
Check if the customer is eligible for loan. If not, no watch device will be recommended for the subscription.
For NBA Mode, identify the recommended device manufacturer for the recommendation based on the customer’s existing devices on
watch and primary subscriptions (Strategy: Identify Manufacturer).
For both RefineBy and NBA modes, watch devices will be retrieved from D_SellablePaymHandsets datapage (DeviceType:"Watch"),
and for each device, stock details will be retrieved from D_GetStockAvailability datapage.
Pick the most expensive watch device for the recommendation.
For RefineBy mode, set error message as “Out Of Stock” if there is no available device (Quantity = 0 and Quantity Status !=” Stock
Details Unavailable”/”Preorderable ”/”Backorderable”) and skip Tariff and Discount calculations.

GetRecommendedTariffForWatch


GetRecommendedTariffForWatch
Substrategy: GetWatchTariffList will provide eligible tariffs for watch subscriptions retrieved from D_EligibleTariffsforDepartment data
page (For now there is only a single tariff for watch subscriptions and the criteria are SegmentofTariff = "Loan" and SIMOnly="Y" and
Category="Access Plan").
Pick the most expensive Tariff for the recommendation.
CalculateDiscountForWatch
Only if the watch customer's primary service number is on the relevant tariff (Tariff Benefit includes keyword "50% off Watch
Connectivity"), watch subscription will be eligible for discount.T1(Higher Data) Strategy: T1Logic TariffBlock = T1 && RecommendedTariffData
> Current Data
T2(Same Data) Strategy: T2Logic TariffBlock = T2 && Check if
RecommendedGroupCoverage >=
CurrentTariffGroupCoverage Otherwise
RecommendedTariffData >= CurrentData
T3(Highest Propensity) Strategy: T3Logic TariffBlock = T3 && Higher propensity Tariff
via Model as compared to logic
T4(Higher then Recommended) Strategy: T4Logic TariffBlock = T4 && Recommendations
Higher then T1Tariff Block Strategy & Decision Data Rule


402
Get the compatible discounts for the recommended tariff from D_DiscountsForTariff data page.
Filter Discount list on Discount Name contains “50% off Smartwatch Connectivity” and Discount Type is Percentage.
Select the max discount value from the list.

DecomposeRecommendation
This strategy will be executed for both handset and watch recommendations
Decompose the recommendations at product level. If Handset product, get handset loan details.
Get the details for auto added addon’s and discounts for the respective recommended tariffs from the below data pages.
Data page: - D_ServicesForTariff - fetch auto added Add-ons related details.
                             D_DiscountsForTariff – fetch auto added discounts related details.


403
Get Product List API
Get Product List API is part of Assisted Upgrade functionality that returns one of the below lists based on the .ProductType passed in the
request context.
1. Device List if .ProductType = Handset
2. Tariff List if .ProductType = Tariff
3. Insurance List if .ProductType = Insurance
4. Addon List if .ProductType = AddOn
5. Discount List if .ProductType = Discount
Along with above, other context and basket (line item) data is also passed that are detailed in following sections.

Pre-requisites
Most of the subscription/customer data is already populated by GetCustomer API call, before making get product list call barring a few,
which are added/composed in:
Data Flow: PrepareDataForGetRecommendation.
Customer intent is also evaluated by calling:
Data flow: IdentifyCustomerIntentsForGetRecommendation.
GetCustomer api call populates Data Set: SubscriptionXCAR. So the customer must be present in this data set for a successful
GetProductList api call.
Data coming from BDC Model is present in below two data sets, both added to Subscription data in .BDCRecommendationList in Data flow:
PrepareDataForGetRecommendation.
1. UniversalTariffRecommendation
2. DeviceRecommendation
Above data sets are populated by BDC Loader.

Sequence of flow is:
Rest API call with a valid request
Activity: GetProductList
Data flow: GetProductList
Strategy: GetProductList - This in turn calls relevant strategies depednding on the product type in request
Logic returns individual SR pages with pre-defined response types and rank along with relevant output attributes to be displayed on the
UI.

Sample API request


UI.

Sample API request
To mimick the actual api call and to test the logic end to end, Soap UI software is used to send the request and get a response. (It’s upto the
developer’s to choose which software to use).
A sample API request will look like below.
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-307578989",


404
"AgentId": "53243463",
"Division": "Webchat Saves",
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Tariff",
"LoanEligibilityStatus": "ELIGIBLE",
"LineItems": [
{
"ProductId": "110017",
"ProductType": "Tariff"
}
]
}
If wrong SubscriptionId is passed, error is {"Error": "Subscription Not Found"}
Get Device List
Returns list of device(s). i) Handsets OR ii) Watches
Strategy: GetDeviceList
The main data page to get tariff data is: D_SellablePayMHandsets that gets data mainly from database view: pc_paym_handset_v and
few other views. DeviceType parameter of the datapage is set as ”Handset” or “Watch” depending on the upgrading subscription type.
Before returning the device list as response, logic needs to check if the top 5 devices have available stock. This is done by calling strategy:
GetStockDetails that calls Data Page: D_GetStockAvailability.

Sample API request - Handset
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",  → The customer
"AgentId": "53243463",
"Division": "Customer Relations",
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",


"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Handset", → Must be Handset
"LoanEligibilityStatus": "ELIGIBLE", → This is important. To check the loan eligibility status.
"LineItems": [ → Line Items not used in get device list logic, but may be present in request.
{
"ProductId": "110017",


405
"ProductType": "Handset"
}
]
}
Sample API request - Watch
{
"OwnerAccountNumber": "3180076771",
"SubscriptionId": "-307578989",
"AgentId": "53243463",
"Division": "Customer Retention",
"Channel": "InboundCC",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "447387988725",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Handset",
"LoanEligibilityStatus": "ELIGIBLE",
"PrimarySubscriptionId": "-212978131", → Customer’s Primary Subscription
"LineItems": [
{
"ProductId": "205572",
"ProductType": "Handset"
}
]
}
Get Tariff List
Returns list of tariff(s) for a watch/non-watch CTN.
Strategy: GetTariffList
The main data page to get tariff data is: D_EligibleTariffsForDept that gets data from database view: pc_eligible_tariffs_dept_v.
For watch subscriptions, GetWatchTariffList sub-strategy will be called which is also used by Get Recommendation Logic.
To calculate maximum discount for a tariff, call is made to sub-strategy: CalculateMaxDiscountForTariff, that uses the Data page:
D_DiscountsForTariff to get data from database view: pc_discounts_tariff_v.
Due to performance concerns count of tariff to calculate “Max Discount” needs to be configurable. To achieve this, a configurable value is
present in AOM Business Config that is retrieved in the logic as:


present in AOM Business Config that is retrieved in the logic as:
D_VFUKFWAOMFWDataAOMBusinessConfig[ConfigType:"MaxRecord",ConfigName:"MaxRecordForTariff"].ConfigValue
AOM Business Config screenshot:


406

Sample API request with Tariff in Basket
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",  → The customer
"AgentId": "53243463",
"Division": "Customer Relations", → Used to get data from data page: D_InsurancesForHandset
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Tariff", → Must be Tariff
"LoanEligibilityStatus": "ELIGIBLE",
"LineItems": [
{
"ProductId": "110017",
"ProductType": "Tariff"  → Tariff in basket
}
]
}
Sample API request with Handset in Basket
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",  → The customer
"AgentId": "53243463",
"Division": "Customer Relations", → Used to get data from data page: D_InsurancesForHandset
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",


407
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Tariff", → Must be Tariff
"LoanEligibilityStatus": "ELIGIBLE",
"LineItems": [
{
"ProductId": "203399", → Check tariff to handset compatibility using DP: D_EligibleTariffsForHandset
"ProductType": "Handset"  → Handset in basket
}
]
}
Sample API request for watch subscription
{
"OwnerAccountNumber": "3180076771",
"SubscriptionId": "-307578989",
"AgentId": "53243463",
"Division": "Webchat Saves",
"Channel": "InboundCC",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "447387988725",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Tariff",
"LoanEligibilityStatus": "ELIGIBLE",
"PrimarySubscriptionId": "-212978131", → Customer’s Primary Subscription
"LineItems": [
{
"ProductId": "112168",
"ProductType": "Tariff"
}
]
}

Get Insurance List
Returns list of Insurance for the handset in the basket.
Strategy: GetInsuranceList
The main data page to get insurance data is: D_InsurancesForHandset that gets data from database view:
pc_insurance_service_handset_dept_v. Records returned by the data page with ServiceGroup3 = Insurance are not considered. Also
optional and mandatory auto added products are not considered.
Sample API request
{


408
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",  → The customer
"AgentId": "53243463",
"Division": "Customer Relations", → Used to get data from data page: D_InsurancesForHandset
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Insurance", → Must be Insurance
"LoanEligibilityStatus": "ELIGIBLE",
"LineItems": [
{
"ProductId": "203399", → Identifier: used to get data from data page: D_InsurancesForHandset
"ProductType": "Handset"  → Must be Handset only
}
]
}
Get AddOn List
Returns list of AddOn for the tariff in the basket.
Strategy: GetAddOnListForEditDeal
The main data page to get add on data is: D_ServicesForTariff that gets data from database view: pc_services_tariff_v.
Sample API request
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",  → The customer
"AgentId": "53243463",
"Division": "Customer Relations", → Used to get data from data page: D_ServicesForTariff
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "AddOn", → Must be AddOn


"ProductType": "AddOn", → Must be AddOn
"LoanEligibilityStatus": "ELIGIBLE",
"LineItems": [
{
"ProductId": "110017", → Identifier: used to get data from data page: D_ServicesForTariff
"ProductType": "Tariff"  → Must be Tariff only
}
]
}


409
Get Discount List
Returns list of discount for the tariff in the basket for a watch connectivity.
Strategy: GetDiscountList
The main data page to get discount data is: D_DiscountsForTariff that gets data from database view: pc_discounts_tariff_v. Auto added
discounts are not considered.
For watch subscriptions, CalculateDiscountForWatch sub-strategy will be called which is also used by Get Recommendation Logic.
Sample API request
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",  → The customer
"AgentId": "53243463",
"Division": "Customer Relations", → Used to get data from data page: D_DiscountsForTariff
"Channel": "retail",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "U-450043",
"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Discount", → Must be Discount
"LoanEligibilityStatus": "ELIGIBLE",
"LineItems": [
{
"ProductId": "111822", → Identifier: used to get data from data page: D_DiscountsForTariff
"ProductType": "Tariff"  → Must be Tariff only
}
]
}

Sample API request - Watch Subscription
{
"OwnerAccountNumber": "3180076771",
"SubscriptionId": "-307578989",
"Division": "Customer Retention",
"Channel": "InboundCC",
"SubChannel": "retail",
"OrderType": "34443",
"CaseId": "447387988725",
"DealId": "1",
"RecommendationId": "U-45004",


"DealId": "1",
"RecommendationId": "U-45004",
"ProductType": "Discount",
"PrimarySubscriptionId": "-212978131", → Customer’s Primary Subscription
"AgentId":"123",
"LineItems": [
{
"ProductId": "112168",


410
"ProductType": "Tariff",
"PriceIncludingVAT": "30"
}
]
}
 Additional plan discounts should be identified in AOM Business Config with AdditionalPlanDiscountCode config name and config
type. Existing APD codes: 110135, 111630, 104883, 112977 (ADO-363828)


411
Validate Basket API
Sequence of flow
1. API call/request
2. Service endpoint URL
”https://pega.data.dev1.vodafoneaws.co.uk/prweb/PRRestService/aom/v1/basket/validate”
(POST method)
3. Activity: ValidateBasket
4. Data flow: ValidateBasket
5. Strategy: ValidateBasket
6. Response back to the API (SR pages)

Sample API request (for end-to-end testing via Soap UI)
{
"OwnerAccountNumber": "049946012",
"SubscriptionId": "-211571596",
"AgentId": "53243463",
"Division": "Customer Relations",
"Channel": "InboundCC",
"SubChannel": "VADR",
"OrderType": "34443",
"CaseId": "U-450043",
"RecommendationId": "U-45004",
"SecondaryContext": "Swap",
"RecentProductType": "Handset",
"RecentProductId": "112332",
"LineItems": [
{
"ProductId": "112332",
"ProductName": "Test Tariff",
"ProductType": "Tariff",
"DisplayName": "Test Tariff",
"Tenure": 12,
"PriceExcludingVAT": 50
},
{
"ProductId": "090856",
"ProductName": "Test Handset",
"ProductType": "Handset",
"DisplayName": "Test Handset",
"MaximumTenure": 14,
"PriceExcludingVAT": 50
}
]


412
}

Configurations
Validate Basket logic calls sub-strategy: CalculateNetRevenue, that calculates Agent’s Commissions.
Strategy CalculateNetRevenue sets below two attributes by getting the values from AOM Business Config.
D_VFUKFWAOMFWDataAOMBusinessConfig[ConfigType:"AssumedAddonTenure",ConfigName:"AssumedAddonTenure"].ConfigValue
D_VFUKFWAOMFWDataAOMBusinessConfig[ConfigType:"SecuredNetServiceIdentifier",ConfigName:"SecuredNetServiceIdentifier"].Confi
gValue

AOM Business Config configuration
CalculateNetRevenue makes a call to Data page: D_ServicesForTariff that gets data from database view: pc_services_tariff_v.


413
Validate Basket logic calls sub-strategy: CheckEarlyUpgradeForBasket that uses Decision Data: UpgradeLifeCycleS15RuleConfig.
This DD holds values that are required to ascetain the GrowS15 flag for the customer. E.g.

Validate Basket logic calls sub-strategies: CalculateBasketFinancials and CalculateMaxDiscountForBasket. These strategies make use
of Decision Data: NetMafAddonListConfig. This DD holds the value for S15Flag (Y or N) for basket’s Insurance and AddOn product
codes. E.g.

To check if the recently added AddOn in the basket is compatible with a service, in Strategy: EvaluateServiceToServiceCompatability,
Data Page: D_InCompServiceIdsForService is called that gets data from database view: pc_service_service_incomp_v.


414
VF Together Offers

VF Together Offers are presented to only Customers having an HBB Account.
Strategy:GetEligibleVFTogetherOffersforAccount
If Customer has an HBB Account, we will find eligible  VF Together Offers by querying below data page
D_CalculatedOffersForUpgrade for each RecommendedTariffCode
(Input : Upgrading MSISDN, Account Number,Department, Channel,TariffID
Output : List of VT Together Offers customer eligible)
For each eligible VF Together offer identify RecommendedTariffcode(as TariffID used in querying) and RecommendedPosition(same
Position of RecommendedTariffCode )

With list of VF Together Offer & qualifier details for account (for each RecommendedTariffCode,RecommendedPosition) identify Offers,
Qualifiers and Rewards by using below strategies
SetOutputPropertiesforVFTOffers(considering  Upgrading Line as offers)
SetOutputPropertiesforVFTQualifierData
SetOutputPropertiesforVFTRewardData
For identifying rewards we use data page
D_EligibleCombiBundleQualifierReward  for each unique CombiOfferId +QualifyingCriteriaID combination
(Input: OfferID ,QualifyingCriteriaID
Output : List of rewards that the offer gives for  QualifyingCriteriaID)


415
Configuring Offers, Offer Variants, Treatments, Treatment Variants
Offers
The assisted upgrade offers are configured under following criteria and apply eligibility rules to identify the eligible offers.
Business Purpose: Renew
Execution Mode : NBAA
Channel: InboundCC
Strategy: IdentifyEligibleOffers, IdentifyEligibleRenewOffers
Configuring Offers in PM Tool
To create a new offer refer to steps in Offer Related Screens.Renew UpgradeMobileToSIMO30 Subscription is NOT Watch AND
Subscription is Consumer
Postpay AND Customer Is Mobile
ServiceNBAA
Renew UpgradeMobileToHandset
 Subscription is NOT Watch AND
Subscription is Consumer
Postpay AND Customer Is Mobile
Service NBAA
Renew UpgradeMobileToSIMO Subscription is NOT Watch AND
Subscription is Consumer
Postpay AND Customer Is Mobile
ServiceNBAA
Renew UpgradeAddOn Subscription is Consumer
Postpay AND Customer Is Mobile
Service  AND Eligible for
Recommendation from CRENBAA
Renew UpgradeHandset is DISABLED Subscription is Consumer
Postpay AND Customer Is Mobile
Service  AND Eligible for
Recommendation from CRENBAA
Renew UpgradeDiscount Subscription is Consumer
Postpay AND Customer Is Mobile
Service  AND Eligible for
Recommendation from CRENBAA
Renew UpgradeDevice Subscription is Consumer
Postpay AND Customer Is Mobile
Service  AND Eligible for
Recommendation from CRENBAA
Renew UpgradeSmartWatch Subscription is Watch NBAABusiness Purpose OfferName Offer Eligibility Execution Mode


416

OfferVariants
OfferVariants are configured under business issue ‘Renew’ and apply below eligibility rules for the respective offer variant to identify the
eligible offer variants.
Offer variant eligibility rules are configured in the Strategy RetentionRules3.
Strategy: ApplyRenewOfferVariationsEligibility
Configuring OffersVariants in PM Tool
To create a new offer variant refer to steps in Offer Variant.

Treatments
Below are the treatments configured for Assisted Upgrade for InboundCC channel. The column  Max children is used for parent child
association.
Only parent treatments are configured with max children in order to make the association with children.
 Configuring Treatments in PM Tool
To configure new treatments for Assisted Upgrade refer to the steps to be configured in PM tool.
Treatment related screens
 Normal !Subscription is SIMO  AND Out of Commitment  AND  CRE Type is
NORMAL
FlexUpgrade !Subscription is SIMO AND !Contract Start day in last 180 days AND
! Out of Commitment  AND  CRE Type is FLEXUPGRADE
NormalSIMOFlex Subscription is SIMO AND Out of Commitment AND CRE Type is
NORMALSIMOFLEX
SIMOFlex Subscription is SIMO AND !Contract Start day in last 14 days  AND !
Out of Commitment  AND  CRE Type is SIMOFLEXOfferVariants Eligibility Rules
UpgradeMobileToHandset_InboundCC InboundCC 3
UpgradeMobileToSIMO_InboundCC InboundCC -1
UpgradeMobileToSIMO30_InboundCC InboundCC 0
UpgradeDiscount_InboundCC InboundCC
UpgradeAddon_InboundCC InboundCC
UpgradeHandset_InboundCC is DISABLED InboundCC
UpgradeDevice_InboundCC InboundCC


UpgradeHandset_InboundCC is DISABLED InboundCC
UpgradeDevice_InboundCC InboundCC
UpgradeSmartWatch_InboundCC InboundCC 10TreatmentName Channel Max Children


417
Treatment Variants
Below are the treatment variants configured for assisted upgrade.
For tariff treatments variants the Recommendation subtype =T1,T2,T3,T4.
For Discount Treatment variants the Recommendation SubType = Upsell,PriceMatrix,Segmentof1
For Service and Handset Treatment variants will be Default.
Strategy: AllTreatmentsForEligibleOffers
To configure new treatment variants in PM tool refer the steps
Treatment Variation

ParentChildTreatments
The bundling of parent and child treatments will happen in the ParentChildTreatments Decision Data. Parent will have the number of
children based on the maxchildren configured in the Treatments.
For example if the Parent has maxchildren as 3, it cannot have more than 3 children. Similarly if the max children value is ‘-1’ the parent can
have any number of children associated.
(Strategy: ApplyBundling)
Decision Data: OfferDecisionMix – provides the max offers for the execution mode and identifies the best treatment for NBAA.
Strategy: IdentifyBestTreatmentForNBAA


418
Fix or Flex
What is Fix or Flex?
Business wants the ability to configure Tariff, Devices as fixed.
If deal contains any “Fixed” product:
- No additional discount will be recommended (exception is promotional discounts)
- Toolkit discounts cannot be added in edit deal journey

How to make a Tariff of Device Fixed?
At product level it is done via PM Tool via attribute: .IsFixed = True or False.
This data from PM Tool is pushed to .ProductAttributes DB table and in relevant data page import > Properties mapping, value is received in
strategy.
For example:
Strategy: G e t R e c o m m e n d e d D e v i c e
Data pages: D_SellablePaymHandsetBySKU and D_SellablePaymHandsets
.RecommendedDeviceIsFixed = @if(@String.equalsIgnoreCase(.ProductAttributes(IsFixed),"True"),true,false)

Strategy: GetListofActiveTariffs
Data page: D_EligibleTariffsForDept
.RecommendedTariffIsFixed = @if(@String.equalsIgnoreCase(.ProductAttributes(IsFixed),"True"),true,false)

There are few other strategies related to tariff and device, where above attributes are retrieved as required, via relevant data import. More
details are present in the design document.

Also global level configurations will enable or disable fix flow via DD: GlobalFixedProductConfiguration in Strategy:
GetGlobalFixedProductConfiguration.
This strategy will determine the value of an attribute .IsFixedEnabled.

So, till now we have values for the 3 required attributes in the tariff/device strategies:
.RecommendedDeviceIsFixed, .RecommendedTariffIsFixed, .IsFixedEnabled

And, final values based on the above are:


And, final values based on the above are:
.RecommendedDeviceIsFixed = true if .RecommendedDeviceIsFixed = true && .IsFixedEnabled = true
.RecommendedTariffIsFixed = true if .RecommendedTariffIsFixed = true && .IsFixedEnabled = true

Configuring Decision Data: GlobalFixedProductConfiguration


419
The 3 main attributes of the DD are:
- FixedProductEnabledChannel
- FixedProductEnabledTeam
- FixedProductEnabledOrderTypes
And the unique key is combination of FixedProductEnabledChannel and FixedProductEnabledOrderTypes.
Values in the DD are compared with values of .Channel, .Team and .OrderType. If the values match or the value in DD for an attribute is
‘ALL’, the device of tariff is marked fixed i.e. .IsFixedEnabled = true.

Example snapshots of the DD


420
Validate Delete API
Validate Delete API call is triggered when an AddOn or Insurance is deleted from the basket. It checks if PostS15 is higher or equal to
PreS15 in case if the customer is in Early Upgrade period. If the condition is not provided, selected item won’t be deleted from the basket.
Sequence of Flow:
1. API call/request
Service endpoint URL
https://pega-realtime.data.dev1.vodafoneaws.co.uk/prweb/PRRestService/aom/v1/basket/delete
2. Activity: ValidateDelete
3. Data flow: ValidateDelete
4. Strategy: ValidateDelete
5. Response back to the API (SR pages)

Sample API request
{
        "AgentId":"53243463",
        "CaseId":"U-244002",
        "Channel":"InboundCC",
        "Division":"Webchat Saves",
        "LoanEligibilityStatus":"Eligible",
        "OrderType":"Upgrade",
        "OwnerAccountNumber":"XXXXXXX",
        "PrimaryContext":"ValidateDelete",
        "RecentProductId":"106211",
        "RecentProductType":"AddOn",
        "S15PostMAFDelta":"23.7346667",
        "SecondaryContext":"Delete",
        "SubscriptionId":"-XXXXXXX",
        "LineItems":[
          {
                  "ProductType":"Handset",
                  "ProductId":"205146",
                  "ProductName":"Apple iPhone 11"
          },
          {
                  "ProductId":"112685",
                  "ProductName":"Bingo Test B Gold 24 month Unlimited",
                  "ProductType":"Tariff",
                  "ChildLineItems":[
                  {
                        "Classification":"Promotion",
                        "PriceExcludingVAT":"121.6",
                        "ProductId":"106211",


"PriceExcludingVAT":"121.6",
                        "ProductId":"106211",
                        "ProductName":"Red+ Threshold 4GB",
                        "ProductType":"AddOn"
                   }


421
         ] } ]
}
Sample API response
If Addon or Insurance can’t be deleted DisplayMessage will be set as “Please select a higher tariff in order to delete this add on", otherwise
no response will be returned.


422
Conditional investigation For RT APIs
Summary
This new capability will enable easier debugging/investigation functionality for all real-time call to AOM by writing conditionally to new C*
Data Sets. The following DFs will be updated to provide this functionality .
A. GetNBA (TradeIn, IVR)
Refer D section in Below page.
NBA FW - Conditional investigation function for RT APIs
B. GetAssistedUpgrade (VADR)
 Refer F section in Below page.
NBA FW - Conditional investigation function for RT APIs


423
Extractor Failure Scenario when Batch is Triggered

As part of the R2.8 ADO: 370027 Revalidation for Batch is introduced.
Whenever extractor run is failed due to some reason for batch and if the Email and SMS has been sent to few eligible customers. After
rectifying the extractor issue and re-running the extractor again will avoid sending Email and SMS to the customers who already been
received Email/SMS on that specific Extractor failed day with this new feature introduced as part of R2.8.
So, for the other channels apart from Email and SMS, current extractor case logic handles the failure scenario like deleting failed extractor
case records from the IH and removing files generated .
For example, if the Treatments got eligible for OBCC Channel and written to IH for few customers and in between due to some reason
extractor is failed. Then after rectifying the extractor case issue and re-run of the extractor removes previously entered records in IH. And
inserts again records in the IH for the eligible customers in IH and creates new files for that.
But, when extractor failed after Email/SMS is sent to the few customers. With the current Revalidation for the batch simply
Reconfigure(Suspend and re-submit) the Campaign and run the Campaign again. This makes sure that Email/SMS is not sent twice on that
day after the extractor issue is sorted out.

Important Notes: In the data type AOMBusinessConfig, number of days is defined that how many days contention should be applied for
Email and SMS channels. By Default it is 0(It means on the same extractor failure day, if issue is resolved and re-ran then Email/SMS will
be not sent who already received on that day.)


be not sent who already received on that day.)
If the extractor is failing today and the issue is resolved on the following day, then the values should be modified to 1 before the extractor
run(so it avoids Email/SMS will be not sent who already received on the extractor failure day)
Similarly, modify the value in the data type accordingly( Value should be the number of days between Extractor Failed Day and Extractor
Resolved Day(Note: Re-running the extractor on the day it is resolved))
 EmailRevalidationPeriod Email 0
SMSRevalidationPeriod SMS 0Config Name Config TypeValue
EmailRevalidationPeriod Email 1
SMSRevalidationPeriod SMS 1Config Name Config TypeValue


424
OPTI KT: Second Line Digital Private Pricing
Objective
Digital platform calls AOM’s 2nd line private pricing functionality via API calls, to get a list of prioritised tariff plans, associated percentage
discounts along with associated offers for a customer with an existing primary line product.
This functionality is a part of existing APIs: GetNBA and GetProductList.
Business Purpose = CrossSell
Currently implemented only for CrossSell but has the scope to be extended to other business purposes.
Channel in the API request = Web
OrderType in the API request = In Life Sales
This is passed in Get Product List API request to identify that the request is related to a 2nd line journey.
For GetNBA, it is hard coded as ‘In Life Sales’ in the logic.

Test Cell Management is new in 2nd Line PP, that is described in a separate section in the later part of this documentation.

GetNBA API:
2nd Line PP is called in the GetNBA logic flow only for Offers for below Configuration
@String.contains(.OfferCategory,"ADDITIONAL LINE") && @String.equalsIgnoreCase(.Channel,"Web") &&
@String.contains(.ProductGroup ,"Mobile")
GetNBA request can either come from the 'Upgrades & Offers' page or the 'Options to Buy (OTB)' popup on the Digital platform.
Logic distinguishes between these two sub-channels and determines which offers, treatment and templates to use.
So SubChannel under the Web channel are:
'Purchase' - for 'Options to Buy (OTB)' popup
'UpgradesAndOffers' - for 'Upgrades & Offers' page

Sample GetNBA API request with SubChannel = Purchase and PrimaryContext = Options_to_Buy
{
Identifier: {
Account: {
AccountNumber: "31521130702",


{
Identifier: {
Account: {
AccountNumber: "31521130702",
Status: "Existing",
Type: "Consumer"
},
ServiceNumber: "447920130702"
},
RequestorDetail: {
Channel: "Web",
SubChannel: "Purchase"
},
Context: {


425
PrimaryContext: "Options_to_Buy",
NoOfActions: 5,
Detail: []
}
}
Sample GetNBA API request with SubChannel = UpgradesAndOffers and PrimaryContext = Upgrades_and_Offers
{
Identifier: {
Account: {
AccountNumber: "31521130702",
Status: "Existing",
Type: "Consumer"
},
ServiceNumber: "447920130702"
},
RequestorDetail: {
Channel: "Web",
SubChannel: "UpgradesAndOffers"
},
Context: {
PrimaryContext: "Upgrades_and_Offers",
NoOfActions: 5,
Detail: []
}
}

GetProductList API:
Get Product List gets a list of available tariffs and discounts. There is no Business requirement for templates here.
Sample GetProductList API request with Tariff in Line item (basket)
{
"OwnerAccountNumber": "169806809",
"SubscriptionId": "-127975494",
"AgentId": "53243463",
"Division": "Webchat Saves",
"Channel": "Web",
"SubChannel": "UpgradesAndOffers",
"OrderType": "In Life Sales",
"CaseId": "CaseId",
"RecommendationId": "RecommendationId",
"ProductType": "Tariff",
"LoanEligibilityStatus": "Eligible",
"LineItems": [
{
"ProductId": "112168",
"ProductType": "Tariff"
}
]
}


426
Sample GetProductList API request with Handset in Line item (basket)
{
"OwnerAccountNumber": "169806809",
"SubscriptionId": "-127975494",
"AgentId": "53243463",
"Division": "Webchat Saves",
"Channel": "Web",
"SubChannel": "UpgradesAndOffers",
"OrderType": "In Life Sales",
"CaseId": "CaseId",
"RecommendationId": "RecommendationId",
"ProductType": "Tariff",
"LoanEligibilityStatus": "Eligible",
"LineItems": [
{
"ProductId": "204523",
"ProductType": "Handset"
}

For both the APIs, response is sent to Digital, and Pega writes records to Interaction History and Interaction History reporting.

Error Scenarios
When the APIs are called, if the MSISDN is not recognised by AOM then an error should be returned.
Likewise, if the supplied SKU is not recognised against any non-SIMO plan, then an error should be returned.


427
OPTI KT Second Line Private Pricing
Configuration of Second Line Private Pricing Offer:
Offers - created via PM Tool Offer screen.
AddTablet
Offer “AddTablet” is Configured.
Map applicable channels.
Map applicable execution mode.

OfferVariation Screen
Configure OfferVariations


428
OfferToOfferVariation Screen
Map OfferVariations to Second Line Offers

Treatment Screen
Configure WEB Treatments for Second Line Offers


429

In Strategy: PopulateOutputPropertiesForApp and PopulateOutputPropertiesForGetNBA the content to be displayed in My Vodafone App is
populated from two Decision Data - T2TVAttributes and T2TVActions.
Decision data: T2TVAttributes - provides content of the page.
Decision data: T2TVActions - defines actions for buttons on the page.
Data for above decision data is configured in PM Tool (explained in the next section ‘PM Tool Screens’).

T2TVAttributes (Treatment To Treatment Variations Attributes)
This decisio data holds Content of page
 T2TVActions (Treatment To Treatment Variations Actions)
This decision data holds information of the Button actions i.e. what needs to be done for a button click

PM Tool Screens


430
There are no separate screens for the two main decision data: T2TVAttributes and T2TVActions. Instead data from a combination of
screens in PM Tool is sent to the above mentioned decision data.
Screen: Channel
Below is a screenshot of Channel screen.
1. New channel “WEB” is created.
2. Possible outcomes are added e.g. “Clicked”
3. Tick, if templates are required for the channel.
4. Tick, if Actions are needed on the template e.g. buttons.

Screen: Template Attributes
1. Used to create new template attribute, example - “ImageURL” attribute

Short Text (Single-Line Datatype) 256
Long Text (Multi-Line Datatype) 4000Attribute Max Length


431

 Screen: Template
1. New templates “WebUpgradesAndOffers” and “WebPurchase“ are created.
2. Add Attributes to new template
Later data is added to the template from Treatment To Treatment Variations screen.

Screen: Action Attributes
Allows to create action attributes, new attribute is created “URL”


432
Screen: Actions
A new action is created from ‘Actions’ screen.
1. New Action “WebClickedAction” is created.
a. Add Attributes to new template
2. Data is added to the action from Treatment To Treatment Variations screen.

Screen: TreatmentToTreatmentVariations
For a specific Treatment Variant, Configure Templates and Outcomes created in other screens


433

Templates section:

Outcomes section:


434

Request Body:
{
"Identifier": {
"Account": {
"AccountNumber": "78101117",
"Status": "Existing",
"Type": "Consumer"
},
"ServiceNumber": "447077101123"
},
"RequestorDetail": {
"Channel": "WEB",
"SubChannel": "UpgradesAndOffers"
},
"Context": {
"PrimaryContext": "Upgrades_And_Offers",
"NoOfActions": 0,
"Detail": []
}
}
 Response:
{
   "InteractionId": 2110594958894618725,
   "ActionList": [   {
      "Propensity": 0.25,
      "Priority": 2,
      "OfferVariant": "OfferVariantDefault",
      "Channel": "WEB",
      "SubChannel": "UpgradesAndOffers",
      "OfferId": "XSL021",
      "OfferName": "AddMifi",


435
      "TreatmentId": "XSL025-01",
      "OfferDescription": "",
      "TreatmentVariant": "TreatmentVariantDefault",
      "Detail":       [
                  {
            "Value": "SIMO",
            "Name": "journey"
         },
                  {
            "Value": "15.0 discount just for you",
            "Name": "sash"
         },
                  {
            "Value": "Up to 15.0 on an additional selected SIM only plan with Vodafone. Just a little thank you from us.",
            "Name": "body"
         },
                  {
            "Value": "Keep your phone and get Extra Discounts on a SIMO plan just for you",
            "Name": "title"
         }
      ],
      "TreatmentName": "AddMifi_WEB"
   }],
   "CustomerId": "PP2L-SUB-101123-STF"
}


436
OPTI KT: Test Cell Management in 2nd Line Private Pricing
TestGroups can be mapped to Second Line Offers in Offer Screen.
Note: Only one TestGroup can be mapped to Offer.

In Test Cell Management Screen , TestGroups, TestGroupExpiry, TestGroup enable / disable is configured.
Cell Code is generated in sequential order with test group name. Initial value of a test cell should be equal to Final value of previous test cell
plus(+) one.
TestGroup Split is dependent on business need.
Once Test Group value is entered, two default test cells are populated as below and test cells range should be from 1-100.
Initial value for the first test cell and Final value for the last test cell are disabled
Note: This Screen pushes data into two seperate decision datas TestGroups and TestCells


437
TestGroups Decision Data:

TestCells Decision Data:

AdditionalLineDiscount Matrix: There is no seperate screen in PM tool for conffiguring discount codes. Note: This should be manually
uploaded in system.
Decision Data Example:


438
OPTI KT: GetNBA Logic

Strategy: IdentifyEligibleOffers
As part of re-design, TestCellManagement is invoked at Offer Level
Note: This change ensures that Test Cell Management is available for all offers for all execution modes with the caveat that ineligible offers
may be allocated a test cell but not used.
TestGroups and TestCells Decision data is used in TestCellManagement Strategy
Strategy: IdentifyTestCell
As part of re-design IdentifyTestCell Strategy is modified.
Note: Same Cell Code must be allocated for offers belonging to same test group irrespective of their business purpose
In the existing GetNBA logic, 2nd line private pricing functionality is called in the below strategy when
@String.contains(.OfferCategory,"Additional Line")&&@String.contains(.ProductGroup,"Mobile")
Strategy: PopulateOutputPropertiesForWeb
The strategy is called from PopulateOutputPropertiesForWeb when Execution Mode is GetNBA
Strategy: AssignDiscountToAdditionalLineOffers Strategy


439
ManageAdditionalLineDiscount Strategy:
Strategy input is Discount Treatments with tariff details. In this strategy, Discount Identifiers are set from DiscountMatrix if
TariffType,TariffTier,CellCode and Duration Conditions are met otherwise default discount identifier is set from  OffertoOfferVariation.
Note: AdditionalLineDiscountMatrix decision data is invoked in this strategy
DiscountCompatibilityCheck Strategy:
Compatible of tariffs to discount is calculated in this strategy and return both compatible and non compatible tariffs. Non Compatible tariffs
discount codes are overridden to null.
GetDiscountProductDetails Strategy:
Both Compatible and Non Compatible tariffs are an input to this strategy. Discount Amount is calculated only for compatible tariffs. This
strategy returns both compatible and non compatible discount tariffs.
GetHeadlineDiscount  Strategy:
Finding max discount only for Legally Compliance records
Note: LegalRequirement is configured in AOMBusiness Config. Only Decimals should be configured

Strategy: PopulateOutputPropetiesForGetNBA
GetNBA outputs are inf the form of offers/propositions e.g. parent could be the Tariff offer and discount offer is child.
In the logic flow, screenshot below, Parent Offer for Tariff flows throught the top path.
Below that is the Child offer route for Discount. In API response discounts are present in the Detail section.


440
Finally Disounts are joined with Tariffs.


441
OPTI KT: Get Product List Logic
Strategy: GetProductList is the main strategy.

It calls sub-strategy GetProductListForUpgrade and GetProductListForAdditionalLine that contains the existing GetProductList logic for
Upgrades and the 2nd Line Pricing logic respectively.
Switch component chooses the relevant route based on the .OrderType from API request context.
Call Strategy: GetProductListForUpgrade if .OrderType is "Upgrade" or “Flexi Upgrade"
Call Strategy: GetProductListForAdditionalLine of .OrderType is "In Life Sales"
Set .ErrorMessage = “Invalid Order Type” otherwise

Strategy: GetProductListForAdditionalLine

Note: As part of re-design TestCellManagement is invoked at Offer level.
GetAllTariffs Strategy:


442
Notes: With new logic changes:
AddMobileWithHandset - Include tariffs where tariff type is Handset
AddSIMO - Include all tariffs where tariff type is either Handset or SIMO

GPL Second Line PP Request Body:
{
"SubscriptionId": "PP2L-SUB-100766-STF",
"ServiceNumber": "447077100766",
"OwnerAccountNumber": "78100766",
"AgentId": "SuperSave",
"RecommendationId":"RecommendationId",
"Division": "*",
"ParentDivision":"False",
"Channel": "Web",
"SubChannel": "UpgradesAndOffers",
"OrderType": "In Life Sales",
"CaseId" : "123456",
"ProductType": "Tariff",
"SubscriptionType": "Mobile Broadband Service",
"LoanEligibilityStatus": "Eligible",
"Detail": [
{
"Name":"SIMO",
"Value":"False"
},
{
"Name":"UPGRADE_TYPE",
"Value":"FLEXUPGRADE"
},
{
"Name":"NO_RECOMMENDATIONS",
"Value":"5"
}
],
"LineItems": [
{
"ProductId": "211010",
"ProductType": "Handset"
}


443
]
}

Response Body:
{"LineItems": [
{
"ProductName": "36mth Band 0A Tablet Unlimited Business Plan",
"ProductId": "114190",
"Tenure": 36,
"IncludesCombiBundleOffer": false,
"DisplayName": "36mth Band 0A Tablet Unlimited Business Plan",
"Propensity": 0,
"Position": 1,
"Priority": 0,
"ProductType": "Tariff",
"Data": "9437184",
"ChildLineItems": [      {
"ProductName": "37 mth discount: 10% off line rental",
"ProductId": "114436",
"DisplayName": "37 mth discount: 10% off line rental",
"Propensity": 0,
"Position": 6,
"Priority": 0,
"ProductType": "Discount",
"DiscountAmount": 10,
"DiscountType": "Percentage",
"PriceType": "DISCOUNT"
}],
"DiscountType": "Percentage"
},
{
"ProductName": "36mth Band 0A Tablet Business Plan 12GB",
"ProductId": "114187",
"Tenure": 36,
"IncludesCombiBundleOffer": false,
"DisplayName": "36mth Band 0A Tablet Business Plan 12GB",
"Propensity": 0,
"Position": 5,
"Priority": 0,
"ProductType": "Tariff",
"Data": "12288",
"ChildLineItems": [      {
"ProductName": "37 mth discount: 10% off line rental",
"ProductId": "114436",
"DisplayName": "37 mth discount: 10% off line rental",


"DisplayName": "37 mth discount: 10% off line rental",
"Propensity": 0,
"Position": 3,
"Priority": 0,
"ProductType": "Discount",
"DiscountAmount": 10,


444
"DiscountType": "Percentage",
"PriceType": "DISCOUNT"
}],
"DiscountType": "Percentage"
},
{
"ProductName": "36mth Band 0A Tablet Business Plan 6GB",
"ProductId": "114186",
"Tenure": 36,
"IncludesCombiBundleOffer": false,
"DisplayName": "36mth Band 0A Tablet Business Plan 6GB",
"Propensity": 0,
"Position": 4,
"Priority": 0,
"ProductType": "Tariff",
"Data": "6144",
"ChildLineItems": [      {
"ProductName": "37 mth discount: 10% off line rental",
"ProductId": "114436",
"DisplayName": "37 mth discount: 10% off line rental",
"Propensity": 0,
"Position": 2,
"Priority": 0,
"ProductType": "Discount",
"DiscountAmount": 10,
"DiscountType": "Percentage",
"PriceType": "DISCOUNT"
}],
"DiscountType": "Percentage"
},
{
"ProductName": "36mth Band 0A Tablet Business Plan 2GB",
"ProductId": "114185",
"Tenure": 36,
"IncludesCombiBundleOffer": false,
"DisplayName": "36mth Band 0A Tablet Business Plan 2GB",
"Propensity": 0,
"Position": 3,
"Priority": 0,
"ProductType": "Tariff",
"Data": "2048",
"ChildLineItems": [      {
"ProductName": "37 mth discount: 10% off line rental",
"ProductId": "114436",


"ProductId": "114436",
"DisplayName": "37 mth discount: 10% off line rental",
"Propensity": 0,
"Position": 1,
"Priority": 0,
"ProductType": "Discount",
"DiscountAmount": 10,
"DiscountType": "Percentage",


445
"PriceType": "DISCOUNT"
}],
"DiscountType": "Percentage"
},
{
"ProductName": "36mth Band 0A Tablet Unlimited Max Business Plan",
"ProductId": "114191",
"Tenure": 36,
"IncludesCombiBundleOffer": false,
"DisplayName": "36mth Band 0A Tablet Unlimited Max Business Plan",
"Propensity": 0,
"Position": 2,
"Priority": 0,
"ProductType": "Tariff",
"Data": "9437184",
"ChildLineItems": [      {
"ProductName": "37 mth discount: 10% off line rental",
"ProductId": "114436",
"DisplayName": "37 mth discount: 10% off line rental",
"Propensity": 0,
"Position": 7,
"Priority": 0,
"ProductType": "Discount",
"DiscountAmount": 10,
"DiscountType": "Percentage",
"PriceType": "DISCOUNT"
}],
"DiscountType": "Percentage"
}
]}


446
OPTI KT MVA- Full Screen Promo
Objective
When app is launched, My Vodafone App shoud support a full screen pop-up window, containing a single-offer promotion. This window will
appear once. To support this new sub channel called FullScreenTakeover is introduced
This functionality is a part of existing API: GetNBA
Notes:
AOM will control which offers have full-screen promotions and whether they are returned to the App. Full screen offers will be provided in
addition to the Discover offers.
Only 1 full screen promotion will be returned per call. If multiple offers have full screen promotions then AOM will pick the best, based on
standard arbitration logic.
Whenever a full screen promotions is returned the call must also contain a corresponding Discover offer, which should have position #1
in the Discover carousel.
We will pick the full screen promotion from the top N discover offers. If none have an FSP then no FSP will be returned.

Configuration of MVA FullScreen Offer:
Offers - created via PM Tool Offer screen.
AddBroadbandProExtra
New Offer “AddBroadbandProExtra” is created.
Map applicable channels.
Map applicable execution mode.


447
OfferVariation Screen
Configure OfferVariations
OfferToOfferVariation Screen
Map OfferVariations to MVA FullScreenPromo Offers


448
 Screen: SubChannel
Configure new subchannel 'FullScreenTakeover' to an existing App channel

Treatment Screen
Configure App Treatments for App Offers
 Enable Subchannels for treatments


449

TreatmentToSubchannels:

T2TVAttributes (Treatment To Treatment Variations Attributes)
This decision data holds Content of page
 T2TVActions (Treatment To Treatment Variations Actions)
This decision data holds information of the Button actions i.e. what needs to be done for a button click

PM Tool Screens
There are no separate screens for the two main decision data: T2TVAttributes and T2TVActions. Instead data from a combination of
screens in PM Tool is sent to the above mentioned decision data.
Screen: Channel
Below is a screenshot of Channel screen.
1. New channel “App” is created.
2. Possible outcomes are added e.g. “Clicked”
3. Tick, if templates are required for the channel.
4. Tick, if Actions are needed on the template e.g. buttons.
TreatmentToSubChannel
sNonPropositions TrackYourOrder_App App FullScreenTakeover
TreatmentToSubChannel
sNonPropositions AddBroadbandProExtra_
AppApp FullScreenTakeover
TreatmentToSubChannel
sNonPropositions AddSmartwatch_App App FullScreenTakeoverpyGroup pyIssue TreatmentName Channel TargetSubChannel


450

Screen: Template Attributes
1. Used to create new template attribute, example - “ImageURL” attribute

Screen: Template
1. New template “AppFSPDefault” is created.
2. Add Attributes to new template
Later data is added to the template from Treatment To Treatment Variations screen.


451

Screen: Action Attributes
1. Allows to create action attributes, new attribute is created “URL”
Screen: Actions
1. A new action is created from ‘Actions’ screen.
2. New templates “AppFSPClickAction” and “AppFSPDismissAction“ are created.
a. Add Attributes to new template
3. Data is added to the action from Treatment To Treatment Variations screen.


452

Screen: TreatmentToTreatmentVariations
For a specific Treatment Variant, Configure Templates and Outcomes created in other screens

Templates section:


453

Outcomes section:

Request Body:
"{
"Identifier": {
"Account": {
"AccountNumber": "89289",
"Status": "Existing",
"Type": "Consumer"
},
"ServiceNumber": "447920770018"
},
"RequestorDetail": {
"Channel": "App",
"SubChannel": "Discover"
},


454
"Context": {
"PrimaryContext": "",
"NoOfActions":10,
"Detail": [
]
}}"
Response Body:
"{
"InteractionId": -7492870612923041121,
"ActionList":    [
{
"Propensity": 0.25,
"Actions":          [
{
"Type": "Button",
"Outcome": "Dismissed",
"Id": "AppFSPDismissAction",
"Detail":                [
{
"Value": "Vodafone logo
"Name": "url"
},
{
"Value": "Shop now",
"Name": "label"
},
{
"Value": "Dismissed",
"Name": "action"
},
{
"Value": "1",
"Name": "index"
}
]
},
{
"Type": "Button",
"Outcome": "Clicked",
"Id": "AppFSPClickAction",
"Detail":                [
{
"Value": "Vodafone logo
"Name": "url"
},
{
"Value": "Shop now",
"Name": "label"
},
{


455
"Value": "ReDirect",
"Name": "action"
},
{
"Value": "1",
"Name": "index"
}
]
}
],
"OfferVariant": "Apple",
"Priority": 1,
"Channel": "App",
"SubChannel": "FullScreenTakeover",
"OfferId": "XSL011",
"OfferName": "AddSmartwatch",
"TreatmentId": "XSL011-T0004",
"OfferDescription": "",
"TreatmentVariant": "AppleSmartWatch",
"Detail":          [
{
"Value": "Vodafone – Our Best Ever Network | Now With 5G
"Name": "imageURL"
},
{
"Value": "Treat yourself to a new watch ",
"Name": "title"
},
{
"Value": "Get the Apple Watch Series 6 ",
"Name": "body"
}
],
"TreatmentName": "AddSmartwatch_App"
},
{
"Propensity": 0.25,
"Actions":          [
{
"Type": "Button",
"Outcome": "Clicked",
"Id": "AppDirectToURLAction",
"Detail":                [
{
"Value": "Vodafone logo
"Name": "url"
},
{
"Value": "Shop now",
"Name": "label"
},


456
{
"Value": "ReDirect",
"Name": "action"
},
{
"Value": "1",
"Name": "index"
}
]
},
{
"Type": "Button",
"Outcome": "Clicked",
"Id": "AppDirectToDismissed",
"Detail":                [
{
"Value": "Vodafone logo
"Name": "url"
},
{
"Value": "DiscoverDismissed",
"Name": "label"
},
{
"Value": "ReDirect",
"Name": "action"
},
{
"Value": "1",
"Name": "index"
}
]
}
],
"OfferVariant": "Apple",
"Priority": 1,
"Channel": "App",
"SubChannel": "Discover",
"OfferId": "XSL011",
"OfferName": "AddSmartwatch",
"TreatmentId": "XSL011-T0004",
"OfferDescription": "",
"TreatmentVariant": "AppleSmartWatch",
"Detail":          [
{
"Value": "Vodafone – Our Best Ever Network | Now With 5G
"Name": "imageURL"
},
{
"Value": "Get the Apple Watch Series 6 ",
"Name": "body"


457
},
{
"Value": "Treat yourself to a new watch Discover ",
"Name": "title"
}
],
"TreatmentName": "AddSmartwatch_App"
}
],
"CustomerId": "2-FSP_Crosssell"
}"

FSP Request a …
26 Sep 2022, 08:19 AMrs.json
 FSP Request a …
26 Sep 2022, 08:16 AMer.json


458
Scenario Based Templating
Templates will include a new dimension called “Scenario” in addition to “TreatmentVariation” and “SubChannel”
Use of Templates will remain optional
If a TreatmentVariation does not use SubChannel functionality, “Default” SubChannel will be used
The main template returned by decisioning funnel will be configured as “Default” scenario
Additional “alternate” scenarios will be configured to manage different templates by scenarios - such as Inactive, Expired, Ineligible,
OrderConfirmed, OrderFailed etc.
Use of “alternate” scenarios will be bespoke to channel and as per use cases
“Scenario” used will be written to IH
“Actions” will be updated to be based on Templates
The above changes will be applied for existing IVR template management (GetNBA), 2nd Line Pricing (GetNBA), Assisted Upgrade and
new Landing Pages functionality but will be available to any modes that use Template functionality
Note:
From now T2TVAttributes DD under All Squads contain Scenario column
From now T2TVActions DD under All Squads contain Scenario and TargetSubChannel column
I. Changes for IVR Channel (GetNBA)
Updated below Strategies to add extra join Conditions to include new Scenario SR property while joining Actions and Attributes Data
                     1)PopulateOutputPropertiesForGetNBA
                     2)IdentifyT2TVariationActions
II.  Changes for 2nd Line Pricing (GetNBA)
Updated below Strategies to add extra join Conditions to include new Scenario SR property while joining Actions and Attributes Data
                     1)PopulateOutputPropetiesForGetNBAPrivatePricing
III. Changes for InboundCC Channel (VADR)
Updated below Strategies to add extra join Conditions to include new Scenario SR property while joining Actions and Attributes Data
                     1) PopulateOutputPropertiesForNBAA


1) PopulateOutputPropertiesForNBAA
IV.  Changes for LandingPages (Microsite)
Updated below Strategies to add extra join Conditions to include new Scenario SR property while joining Actions and Attributes Data
                     1)GetInactiveMicrositeTreatment
                     2)GetExpiredMicrositeTreatment
                     3)GetIneligibleMicrositeTreatment


460
Extras Landing Page KT
Introduction
Objective of Extras Landing Page is to display a web page (developed in Microsite), when customer clicks a link inside a SMS. The web
page presents the customer with some offers e.g. 1GB or 2GB of extra data.
Pre-requisite: NBA Batch or T2S has sent SMS to customers. The SMS body contains a link for Microsite, which customer needs to click.
When customer clicks on the link, below Microsite pages are displayed.
Below screenshot shows a Parent offer with 2 child offers, for 1GB and 2GB. The concept of Parent-Child offers or ‘Bundling’ in Pega terms
is explained in later part of this document.
The microsite page displayed for a scenario e.g. success, failure etc. is customizable via template and contents configured in PM Tool.
Parent-Child relationship is configured in a decision data via PM Tool, explained in the ‘Propositions’ section, later in this document.
“Buy Now” button click displays below page i.e. the offer acceptance is being processed.


461
Now, if the customer clicks on the same link, Microsite will not display the accepted offer. Only the remaining eligible offer(s) will be
displayed.

An example of a Parent offer without any child offer is:

This functionality is dev-tested/ST-tested and can be used in all squads.


462
One of the squad example is:
BusinessPurpose = Retain
OfferExecutionMode / ExecutionMode = LandingPages
Channel = Microsite

Sequence of Events
1. NBA Batch Process or T2S sends SMS to customer that has the Microsite link.
2. Customer clicks on the link.
3. App layer will land the customer on Microsite landing page. Microsite is just a Pega Case.
4. Logic layer does re-validation to check if the offer is still available and the customer is eligible for the offer.
5. For re-validation sucess scenario, eligible offer (single Parent OR Parent + Child offers) are displayed.
6. Along with success scenario, that writes Shown outcome in IH, Revalidation process also writes to IH for Inactive, Expired and Ineligible
scenarios. Relevant templates are sent to App layer to display the appropriate Microsite page.
7. If interested in the offer, customer clicks “Buy now” button.
8. CSO (Create Sales Order) logic gets invoked by the App layer.
9. The CSO process, if successful, writes Accepted response in Interaction History. Logic notifies the app layer to display a success
Microsite page.
10. CSO process, if not successful, writes a Failure response in Interaction History. Logic notifies the app layer to display a failure Microsite
page.


463
XLP Propositions and PM Tool Screens
Offers - created via PM Tool Offer screen.
TestOffer3 = Parent Offer
TestOffer4 = Child offer for the Parent offer - representing 1GB
TestOffer5 = Child offer for the Parent offer - representing 2GB

1. New Offer “TestOffer3” is created.
2. Map applicable channels.
3. Map applicable execution mode.


464
ParentChildTreatments decision data
This decision data contains the parent child offer mappings. E.g.
BundleParentTreatment     BundleChildTreatment
TestOffer3_Microsite                       TestOffer4_Microsite
TestOffer3_Microsite                       TestOffer5_Microsite
Offer Bundling set up for Landing pages
Bundling logic for landing pages is done in Strategy: ApplyBundlingForMicrositeTreatments.
Offer bundling logic and set up for Landing pages is same as done for other functionalities. Bundling is needed when there is a requirement
of having Parent and Child offer(s) e.g. Parent offer is Extra Data and child offers could be, 1GB data, 2GB data etc.
Step1: Below two fields (1,2) in Treatment screen needs to be configured for a Parent treatment.


465

In Strategy: PopulateOutputPropertiesForMicrosite (described in ‘XLP Logic Components’ section of this document), the content to be
displayed in Offers Landing Page is populated from two Decision Data - T2TVAttributes and T2TVActions.
Decision data: T2TVAttributes - provides content of the page.
Decision data: T2TVActions -  defines actions for buttons on the page.
Data for above decision data is configured in PM Tool (explained in the next section ‘PM Tool Screens’).

T2TVAttributes (Treatment To Treatment Variations Attributes)
Each Microsite screen displayed is based on a scenario e.g. Default, Success, Failure etc. For an offer/treatment, this decision data holds
information of the template details that needs to be used for a relevant scenario.
The value set in SectionName determines which of the Offers screens to display.
It also holds info of the template to be displayed when there is a single offer or offers with parent child relationship. E.g. if there is a single
parent offer, SectionName = "SingleActionInformationPage".
Possible scenarios are: Default, SuccessScenario, FailureScenario, Ineligible, Expired, Inactive.

T2TVActions (Treatment To Treatment Variations Actions)
This decision data holds information of the Button actions i.e. what needs to be done for a button click based on a scenario.
Possible scenarios are: Default, SuccessScenario, FailureScenario, Ineligible, Expired, Inactive.

PM Tool Screens
There are no separate screens for the two main decision data: T2TVAttributes and T2TVActions. Instead data from a combination of
screens in PM Tool is sent to the above mentioned decision data.
Screen: Channel


466
Below is a screenshot of Channel screen.
1. New channel “Microsite” is created.
2. Possible outcomes are added e.g. “Accepted”.
3. If no subchannel, “Default” value is assigned to the sub channel.
4. Tick, if templates are required for the channel.
5. Tick, if Actions are needed on the template e.g. buttons.
6. Tick, if scenario based templating is needed e.g. change screen templates and content based on scenarios.
7. If Step 6 is checked, scenarios are added e.g. “SuccessScenario”.

Screen: Template Attributes
1. Used to create new template attribute, example - “ExtraLargeImageURL” attribute

Screen: Template
1. New template “Clickid” is created.