Allow Interview Extensions to Access Data Not On a Screen

Note: This feature is only available in Latest Version Interviews.

Generally, interview extensions can only use values of attributes on the same screen. However, you may wish to get an attribute value for an inferred or previously collected attribute without adding it to a screen. You can define which data will be available on every screen for use by custom interview extensions. This allows you to customize navigation and other interview behavior by accessing that data in custom interview extensions. For example, you could have a custom header that summarizes the key details for the interview on each screen, even though that data is not collected on the same screen.

In order to access this data, you need to create a configuration file and include it as a custom file in your project. To do this:

1. Create a file called opm.extension.data.json. This file needs to consist of a JSON array of strings which lists the names of all the attributes and relationships that should be accessible to interview extensions on all screens in the interview. For example, specifying the following for the myBenefit policy model:
   ["app_name", "app_age", "app_citizen"]
   will make the values of those three attributes available to all screens in the interview.
2. Put the opm.extension.data.json file in the /interview-theme/resources folder for your project. (This folder is created when you click the Custom Files button in the Styles dialog box on the Interview tab in Policy Modeling.) The specified data can now be accessed by all interview extensions via the getExtensionData() method on the interview object.

The getExtensionData() method returns a JSON object in this format:

{
    "global": {
        "globalAttribute": "the attribute value",
        "globalDate": "2001-12-24",
        "globalTime": "12:13:14",
        "globalDateTime": "2001-12-14T12:13:14",
        "globalRelationship": [
            "targetInstance1",
            "targetInstance2"
        ],
        "containmentRelationship": [
            {
                "@id": "childInstance1",
                "childRelationship": [
                    "instance1",
                    "instance3"
                ]
                "childNumberAttribute": 42.0,
                "childBooleanAttribute": true
            },
            {
                "@id": "childInstance2",
                "childNumberAttribute": 3.12,
                "childBooleanAttribute": null
            }
        ]
    }
}

Note that:

• In the case where the attribute or relationship belongs to a child entity, then that value in every instance of that entity will be available in the interview.
• Additionally, if the extension data list contains data that is not in the global entity, then the entity to which the attribute/relationship belongs and all its ancestor entities and containment relationships must have names.
• Including data this way can have a major performance impact on the interview, especially if you are including data from a child entity level.

Tip: To see this example in action, copy the following two files into the /interview-theme/resources folder for the myBenefits example project: opm.extension.data and customHeader (JavaScript file that defines the interview extension). Then debug the project to see the custom header on each screen that shows the applicant's name, age and citizenship.