Person Contact Status Can Be Controlled By A Process

Overview

Person contact types can be configured to allow a status. For some person contact types, your implementation may want to control the status through a process instead of allowing the status to be set manually. An example of this is using person contact status to capture opting in for receiving text messages, which is required in some jurisdictions. Opt-in is seeking permission from a customer to use a person contact for a purpose such as sending a customer text messages.

Opt-in works in conjunction with the functionality to enable opt-in for a delivery type. Each can function independently, but together they offer a complete solution. Since they can function apart from each other, each is described independently. See Enabling Opt-in for a Delivery Type for more detail on this logic.

To control a person contact status with a process, the person contact type must first be configured to allow status. The person contact type must then be set up in the opt-in section of the Notification Preferences master configuration. By defining a Status Script, the person contact status can only be changed by the logic contained in or initiated from the script. The product is delivered with a script that creates an opt-in service task. This is designed specifically to support opting in to receiving notifications via text messages (SMS).

Opt-In Process

To use the delivered functionality, configure a new service task type for opt-in. This task type should reference the Notification Preference Opt-In Task Type Business Object (C1-NotifPrefOptInTaskType). The product is delivered with a service task business object The service task is responsible for initiating an opt-in request, updating the person contact status, and logging the user response. An inbound web service receives responses and transitions the service task. These components are designed to integrate with Notification Center. When a customer is sent an opt-in request, they are asked to confirm. The content of the message explains the commands to the user. Examples are CONFIRM or STOP. Notification Center is configured to interpret the specific commands and map them to those expected by the inbound service, which transitions the service task appropriately.

Aside from the initial opt-in request, users can stop or unsubscribe from notifications at any time. The delivered solution supports two modes for this functionality: unsubscribing from all notifications for a particular person contact or unsubscribing from a specific notification type for a particular person contact. This is controlled through configuration, and relies on the external system such as Notification Center to determine the notification type.

The Notification Preferences master configuration help text contains detailed information about the configuration required to control person contact status and setting up opt-in processes.

It is important to note that while the delivered process to control person contact status was designed to work in conjunction with the opt-in process, your implementation can design a custom process that can create a service task or do something completely different. Also, it can be independent of opt-in and notifications. For example, the process can be used to verify that an email address is valid by sending the customer a verification request.

There is another concept, which is enabling opt-in for a delivery type. This is closely related to the functionality described here, but has different implications in the system. See Enabling Opt-in for a Delivery Type for more information.

There is a limitation worth noting. A person contact type may be set up to allow multiple delivery types, however the delivered solution only allows a single delivery type to be associated with the process used to automate person contact status. Without this limitation, different processes would be responsible for updating a single person contact status and those updates could be conflicting.

The System Person Contact Statuses

The opt-in solution delivered with the product utilizes the three delivered status values. They are: Pending, Approved, and Rejected. Your implementation can add your own person contact statuses, but they will not work with the solution delivered with the product. See Setting Up Person Contact Status.

How the System Automates Person Contact Status

There are many ways that the process that controls person contact status can be invoked. For all of these, the person contact type must be set up in the Notification Preferences master configuration to have its status controlled by a process and, unless noted otherwise, the person contact is not already Approved .

The primary way to initiate the process to control person contact status is when a person contact is used to add a contact preference and the contact preference’s delivery type matches the delivery type associated with the person contact type as defined in the Notification Preferences master configuration. This method relies on enabling opt-in for a delivery type. This is how the two processes work with each other. See Enabling Opt-in for a Delivery Type for more information. An example of this scenario is that a person contact exists and is of a type that can receive text messages, such as “Mobile Phone”. Until the person contact is used on a contact preference to receive a notification, there is no reason to initiate an opt-in process.
This process can be automatically initiated by configuring a person contact to default to an initial status of Pending . When a person contact is added, the process is initiated. An example of this scenario is an email person contact initiating a process to verify the email address as soon as it is added to the system.
When the value of an approved person contact is changed, the process is reinitiated. For example, even though the approval is attached to a specific person contact in the system, which has a unique ID, externally the approval was for a particular phone number or email address. When the person contact value (i.e. the phone number or email address) is changed, the prior approval is no longer valid. The person contact status is changed to Pending .

A user can manually initiate the process. A button is provided on the Person Contact row on Person - Main. The button can be used to reinitiate the process when the customer does not have the request and needs it resent. It can also be used to manually initiate the process upfront - before the person contact is used on a contact preference.