Interview Phases

The most simple and common interview experience consists of four phases. Each phase may have one or more interview service actions associated with it depending on the policy model configuration and use case. To see these phases represented diagrammatically, see Data Flow Diagrams.

Phase 1 - Initialize the interview

The first phase when using the interview service involves resuming or starting a new interview session. After this phase you will have an active interview session.

If a session is being resumed, then only the RestoreSession action is performed in this phase using a snapshot captured from a SnapshotSession action during a previous interview session.

If starting a new session, the number of steps required depends on whether the policy model has data mappings which support data to be seeded into the interview. First, the GetInputDataDefinition action is called which returns a description of tables, fields and links to collect data from to pre-seed into the session when the StartInterview action is called. If the policy model has any input data mappings, the response will contain the names of fields to collect data for, and the client application must then collect data from the configured connector using a web service connector API Load action. Finally, the StartInterview action is called including any LoadData that was collected.

Note that because GetInputDataDefinition uses the data model of the connected application, it will be blank unless a web service connection is in use by the policy model. That is, it will be blank for policy models with a data mapping to a B2C Service connection.

Phase 2 - Investigation

The investigate phase refers to the process of collecting data on screens defined in the interview, and intelligently determining which screen to show next by applying rules in the policy model to the data held in the session. This process is conducted through the Investigate action and consists of the following interactions:

  1. The client collects the data associated with the current interview screen, adds it to the screen object and submits it to the Investigate action.
  2. The Interview Service submits the provided data into the session.
  3. Based on the data in the session, the rules and interview definition is evaluated to determine which screen to display next.
  4. The definition of the next interview screen is returned to the next client.

Phase 3 - Submit data

This phase is only triggered on a policy model with output data mappings when a screen with a ScreenAction of submit is submitted to the Investigate action. In that case, instead of responding with the next screen in the interview, the Investigate action will instead return any attachments, audit reports, plus data using a web service connector API's SubmitData structure, which also includes fields mapped to load-after-submit attributes. The client can take the submit data and save it to another application (such as a web service connector) or data store, and then provide the list of data to be updated in the next to the Investigate action, which will submit the data and then return the next screen in the investigation.

It should be noted that a single investigation may consist of multiple investigation and (if data mapped) submit data phases, in which case Phases 2 and 3 will be repeated via the Investigate action until the interview reaches its conclusion.

Phase 4 - End interview

Once the interview is completed, it should be closed via the EndInterview action. After this you no longer have an active interview session.