You are here:
About the Eligibility Framework (Managed Package)
The eligibility framework allows you to specify and control the set of conditions or rules that must be met in order for a requested update to be permitted. Changes to the eligibility conditions or rules can be made without having to update any of the OmniScripts or Integration Procedures used in the workflows.
This feature is part of the Communications Cloud managed package.
The eligibility framework uses a calculation matrix to determine the set of rules applicable to any requested update. Modular, reusable Integration Procedures are used to implement each rule and logical conditions are used to combine multiple rules and return a single pass or fail output for the set of rules.
For example, consider a scenario where a subscriber wants to activate a service. Before you allow this action, you want to check that:
-
The account exists and is active
-
The user who is requesting or performing the action is allowed to do so
-
The SIM card is not suspended and there is no pending suspension request
-
The SIM card is not barred and there is no pending bar request
-
There is no pending SIM card replacement request
-
There is no pending request to change the number
Using a calculation matrix, the eligibility framework allows you to not only control each of these checks at a granular level, but also allows you to reuse each check across various workflows without updating the workflows themselves.
The calculation matrix has the following input and output:
Input/Ouptut |
Column Name |
Type |
Description |
|---|---|---|---|
Input |
Process |
Text |
The name of the workflow for which you want to run the eligibility check. For example, Buy Addon. Using the workflow name makes it easy to search for and identify the appropriate entry in the calculation matrix. For example, when the eligibility framework is used in multiple workflows, if you want to view or edit the set of eligibility rules in a specific workflow, you can search or sort the process column. |
Input |
Check |
Text |
The type of check that you want to perform. In a single workflow, you might want to perform different checks at different stages. For example, initially you might want to check if a user has the appropriate role to perform the requested action. Later on, you might want to check if there are any other preconditions that must be met before the action can be completed. In a calculation matrix, entries in an input column need not be unique, but the combination of entries from all input columns must be unique. So for the type of check, enter a name that indicates what the check does. |
Output |
Rule |
Text |
The set of Integration Procedures that must be called for the given unique input. In the scenario described above, you could create a separate Integration Procedure for each check. In the Rule column, you would then list each of those Integration Procedures separated by the appropriate logical conditions, AND, OR, or braces. So if you want to specify two Integration Procedures performing different checks where both checks must pass in order for the rule to pass, you would use a logical AND. For example: sfi_ActiveAccount AND sfi_AccessBasedOnRoles |
The calculation matrix used by the eligibility framework is set up to perform different types of checks, which are used as required in each of the workflows:
-
InitialEligibilityCheck
This check verifies the subscriber's account status and the role required to perform an action. It also determines the logged in user's role (agent, supervisor, or customer) and verifies that the user is permitted to perform the requested action. For most workflows, the rule for this check calls the following Integration Procedures:
-
SFI-ActiveAccount
-
SFI-AccessBasedOnRoles
-
SFI-CheckValidUserType
-
-
ServiceEligibilityCheck
This check verifies the role required to perform an action. It determines the logged in user's role (agent, supervisor, or customer) and verifies that the user is permitted to perform the requested action. In some workflows, it also determines if there is any other order in progress on the specified subscription or asset. For most workflows, the rule for this check calls the following Integration Procedures:
-
SFI-AccessBasedOnRoles
-
SFI-CheckValidUserType
-
-
CrossOrderCheck
This check determines if there is any other order in progress on the specified subscription or asset. The rule for this check calls the following Integration Procedure:
-
SFI-CrossOrderCheck
-

