With the campaign migration feature, the existing restrictions created using the campaign restriction Flex editor are migrated to the Rule engine.
This migration happens by running the script available in the $POM_HOME/bin folder.
The script parses the existing campaign restriction present in the POM database and creates a separate Attribute and System Restrictions rule for each Restriction node and saves it as a new rule in the pim_rule table.
The migrate_campaign_restrition_to_rule.sh script is triggered during the POM migration.
All the migrated Attribute and System Restrictions rules are available at the top in the global default order list. This implies that the migrated rules are run first than any other created rule.
After moving campaign restriction to the rule engine, the rule evaluation sequence is as follows:
Holiday is evaluated.
Global rules are evaluated based on the order configured.
Campaign-level rules are evaluated.
The following table describes the data used for different fields in the Rule editor. This data is optimized from the existing restriction.
Field |
Campaign Restriction |
Name |
Name of the restriction node_ID. Where name of the restriction node is the existing name that is mentioned in the restriction in campaign restriction. The value of the ID is similar to the ID provided in the restriction node. If name of the restriction node is not provided, verify if the name for the restriction parent is present. If it is present, use the name as parent restrictions node_ID. If no name is provided, use the Migrated_Rule_ID. |
All Organizations |
The existing restrictions are applicable for all organization campaigns. Hence, the All Organizations option is enabled. |
Rule Category |
Attribute and System Restrictions |
Apply To |
All Campaigns |
Restriction On |
Not applicable |
Activate Rule |
Enabled |
Channel type |
Existing Attribute and System Restrictions are applicable for all channels. Hence, all channels are selected. |
Exclude if current attempt type |
No option selected. |
ID |
ID of the existing restriction node. This field is read-only and is displayed only for migrated rules. |
Description |
Description of the restriction node is derived from the existing restriction. |
Restriction Type |
Restriction type selected in the restriction node is derived from the existing restriction. |
Custom Restriction |
For custom restriction node present in an existing restriction, this option is enabled.
Note:
If there is a custom restriction node which has an exception configured, then such exception is not migrated and you need to include that exception in the custom class.
|
Custom Class |
If there is custom restriction node in the existing campaign restriction, migration script copies the custom class name to the Custom Class parameter of the rule. |
Restriction Details |
Existing restriction has the restriction based on the system or contact type. Migration script forms the restriction query based on the restriction provided in the campaign restriction node.
Note:
Existing campaign restriction supports $NOW for the Date type of data type. Where, $NOW+1 works as current day + one day. Migration script changes the $NOW keyword to $TODAY, but the functionality remains unchanged.
The following table displays the mapping of the existing operator to the new rules restriction details operator:
Existing operator |
Rule operator |
contains |
like ( %value%) % is added pre and post of the condition value |
Only Min value |
> |
Only Max value |
< |
Min and Max value where Min is less than Max value |
between |
Min and Max value where Min is greater than Max value |
not between |
equals |
= |
not equals |
!= |
is null |
is null |
is not null |
is not null |
In the existing campaign restriction, a user can provide an exception for the restriction. So, as part of the migration the exception is added to the restriction query as an additional condition (opposite) with the AND operator. For example, an existing Restriction has the following restriction condition: Restrict customer whose payment due is < 10000. Exception to this restriction is that if Credit score is < 400 (do not restrict). Migration script converts this restriction and its exception to Query In Attribute and System Restrictions Rule, payment due < 10000 and Credit score >= 400 Restrict all contact which have payment due less than 10000 and Credit score more than or equal to 400. |
