AgentOne Release Notes

AgentOne August 2019 Release Notes

UAT Release: July 31, 2019 ~12:00pm ET | Production Release: August 16, 2019 ~11:00p ET

New Features

Pending Case Feeds from iPipeline’s Resonant New Business and Underwriting Platform

​​​​​​Description:  iPipeline’s Resonant New Business and Underwriting System is now integrated with AgentOne via a standardized product integration point.

Solution:

AgentOne already supports pending case feeds from carriers’ new business and underwriting systems, in order to provide visibility and proactive alerts on agent’s system engagement via AgentOne on the Salesforce platform.  Now Resonant provides these standardized feeds that support all of the fields and properties that will trigger valuable out-of-the-box AgentOne features and capabilities such as status alerts and agent-assigned requirement alerts.  Any customer who subscribes to both iPipeline’s Resonant and AgentOne will benefit from this robust integration without incurring the costs or the implementation delays associated with a new integration point between their new business and underwriting system and AgentOne.

The following changes in Resonant will trigger a Pending Case feed to be sent to AgentOne.
  • ​Any change to PolicyStatus
  • Any change to a RequirementInfo ReqStatus, including a new Case Requirement (ReqStatus = ADD)
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Underwriting Requirements and Alerts 

Availability: Optional, must be enabled by iPipeline and Resonant

Implementation Steps

The iPipeline AgentOne and Resonant Implementation teams will configure and test for new carrier implementations.

How To Test

New implementations of Resonant with AgentOne will be tested during the implementation process.

  1. In Resonant, make an update to the Case Status to an AgentOne case, or
  2. Add a Requirement in Resonant
Call Center Support

​​​​​​Description:  For AgentOne customers with call centers that support multiple sales representatives marketing to the same unique individual person, AgentOne now supports Salesforce Public Org-wide Defaults (OWD), where all call center reps have visibility or access to one another’s client records (Accounts).  In some cases, unique Accounts are shared across the org, so all of the representatives share the same set of Accounts with only one record representing each unique individual person, defined in AgentOne as Master Client Management or MCM.  Public OWD is different from a traditional life insurance sales or financial advisor model (Salesforce private OWD) where the agents and advisors do not have any visibility to their peers’ client records, so two agents could each have a separate client record for the same unique individual person, with the existence of the other unknown to the other agent.

Solution:
The Salesforce org is set-up with Public OWD to allow all call center reps to see the same Accounts.  Public OWD has both read-only and read/write options that are both supported by AgentOne.  When this feature is enabled in AgentOne, client-matching does not take into account the agent owner.  It just finds any Client that matches on other criteria but is available to the agent.  There are no duplicates of the same client with different agent owners.

​​​​​Risk Analysis: Medium

Affects which Features / Functionality: Opportunity Integration

Availability: Optional, related features must be enabled by iPipeline and Resonant

Admin configures Public Org-wide default for the Account object on the org

Opportunity Integration

​​​​​​Description:  For AgentOne customers with call centers or other business models that leverage the standard Salesforce Opportunity object , AgentOne now supports Opportunity integration features when the sales owner of the Opportunity drives the Insurance Case ownership, rather than the Client.

Solution:

The Salesforce owner of the Opportunity record represents that AgentOne Salesforce User that owns the insurance new business opportunity, rather than the Client owner.  When Opportunity integration is enabled, the iGO user is expected to match the Opportunity owner in most use cases, and the pending case primary writing agent is also expected to match this AgentOne Salesforce user.  Direct changes in the Opportunity Owner will be reflected on any associated iGO cases. Similarly, changes to the primary writing agent in new business and underwriting will impact the Opportunity Owner in Salesforce / AgentOne.

See related Enhancements below

​​​​​Risk Analysis: Medium

Affects which Features / Functionality: Opportunity Integration

Availability: Optional, must be enabled by iPipeline

Note:  In order to leverage the Opportunity object in Salesforce, each user must be assigned a Salesforce base license that includes access the Opportunities, such as Service Cloud, Financial Services Cloud, or Sales Cloud.  Non-CRM Salesforce Platform licenses and AgentOne OEM licenses do not include license to the Opportunity object and therefore AgentOne Opportunity Integration may not be leveraged for users with those base Salesforce licenses.

Direct-to-Consumer (DTC) iGO Integration (added July 25 2019)

​​​​​​Description:  AgentOne users can now view, monitor and manage IGO cases that were created by the consumer for their own insurance protection on the a carrier’s consumer-facing website.

Solution:
Leveraging an iGO direct-to-consumer (DTC) project on a carrier’s marketing website(s), an insurance consumer is able to create and edit their own iGO cases via iPipeline-provided widgets and an alternative iGO user interface that is easy-to-use and consumer friendly.  Via a complete self-service model, the consumer can quote and enter all of the information for the Part A of an insurance application, lock and sign it — all without the help of an agent.

AgentOne can now receive those cases that were originated in iGO DTC, and associate them with a special purpose AgentOne system user specifically designated for all DTC cases.  Call center AgentOne users, and other licensed agent types, can view those Insurance Cases (or the associated Opportunities) and assume responsibility for them, if agent assistance is needed or requested by the consumer, by taking ownership in AgentOne/Salesforce.

​​​​​Risk Analysis: Medium

Affects which Features / Functionality: IGO Integration

Availability: Optional, related features must be enabled by iPipeline

Enhancements

Support new fields to synchronize from iPipeline’s Resonant New Business and Underwriting Feeds

​​​​​​Description: For customers who use both AgentOne and Resonant, the AgentOne Opportunity ID is also passed from iGO into Resonant, and Resonant sends the Pending Case updates to AgentOne.

Solution:

Create a new Entity Field List setting to allow the pending case feed to populate the opportunity lookup field on the insurance case.
The following new Entity Field List setting was created…
Name Entity Name​ Field Name​ Enabled​ Default
​Aa02.opportunity__c ​pendingcaseentry ​opportunity__c TRUE​ TRUE​
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Underwriting Requirements and Alerts

Availability: Automatic

Implementation Steps
None

How To Test

Process a pending case sync record that includes ​’opportunity__c’ with the SF record ID of an existing opportunity as it’s value.

Example:

AORD_5553_example.jpg

Accept ad-hoc Requirement Descriptions from ACORD text

​​​​​​Description:  AgentOne would like to show the ad-hoc Case Requirements added in Resonant.  Previously when a Case Requirement with the Acord code for “Other” – 2147483647 was received by AgentOne, the Requirement Name of “Other” would be ​displayed.  Resonant Case manager allows case managers to enter ad-hoc case requirements.  These ad-hoc case requirement have a code of 2147483647, and an ad-hoc description dynamically and uniquely defined by the case manager.

Solution:
Allow AgentOne to display the requirement description text sent with the ReqCode node where tc=2147483647.

For example, the following Requirement would show “Ad-hoc Requirement Name” as the Requirement Name – <ReqCode tc=2147483647>Ad-hoc Requirement Name</ReqCode>.
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Underwriting Requirements and Alerts

Availability: Automatic

Implementation Steps
None

How To Test
1. Create a Pending Case ACORD file with Requirements of Code as shown  here <ReqCode tc=2147483647>Hello World</ReqCode>
2. Send the Request to AgentOne.
3. Confirm that you see a Requirement with Hello World as the name.
Org-Wide Master Client Management “MCM” for iGO and Pending Cases

​​​​​​Description:  As an AgentOne customer that wants to share clients, I would like the client-matching to identify the existing client record and use that client record, even if it is owned by another user, so that any iGO case (that did not originate in AgentOne) or pending case will use the existing client instead of create a new one.

Solution:
Introduced a new Application Configuration setting which is respected when client-matching finds the Client, even if it is not owned by the primary writing agent (PWA), and use that existing Client regardless of owner.  If a new Client record is required because the client-matching failed, the primary writing agent will own the next Client record.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality:  Call Center Support, IGO Integration, Underwriting Requirements and Alerts, Customer Centricity

Availability: Optional

Implementation Steps
  1. While logged in as an administrative user open the AgentOne Administration app
  2. Go to Application Configuration and change the setting ‘Use Master Client Management’ to TRUE
Note: the default matching logic has been updated to check the application config setting and if ON will use the existing client (even if it is not owned by the AgentOne user set as the primary agent on the case). If the org is configured to use a custom client matching plugin and you would like it to respect the app config setting then that plugin will need to be updated to check the app config setting.
How To Test

1. Enable the app config setting to ‘Use Master Client Management’

2. Change the Account OWD to (Public Read/Write) and make sure the org is configured to receive iGO originated case

3. Login as a system user (e.g. Administrator) and create a new client where the account owner = admin

4. Login as an agent user and start iGO from any case (this step is to create the SSO login)

5. Open a new tab in the same browser session and load iGO (direct log in… “CONNECTED”)

6. Create a new case and enter the same First Name, Last Name, and Birthdate that will match the client created by admin in step 3

7. After you trigger a sync to AgentOne confirm

  1. ​that the new case is created under the existing client owned by admin
  2. that the insurance case has the agent user from step 4 saved to the ‘iGO User’ {iGO_User__c) field
Start iGO from Opportunity

​​​​​​Description: As an AgentOne customer leveraging the Salesforce standard Opportunity object (with a license that provides it), I want to link an Opportunity to an Insurance Case and its iGO case so that I can associate the iGO case with the rest of the information about it in Salesforce.  Then as an agent, I would like the ability to load iGO from the Opportunity that is linked to the AgentOne insurance case record that originated in iGO and was synchronized to AgentOne.

Solution:
When starting iGO from an opportunity (or insurance case with a linked opportunity) and if opportunity integration is enabled on the org, AgentOne uses new productized lookup fields from Opportunity to Insurance Case, and from Insurance Case back to the Opportunity to identify the linked Opportunity and its owner. After identifying the Opportunity owner AgentOne updates the ‘UserData’ info passed in the XML during SSO to iGO, such that it will pass the Opportunity owner instead of the Account/Insurance Case owner as the iGO user.  The ‘UserData’ section in the XML also includes the on behalf of (OBO) user after comparing the logged in user to the opportunity owner to determine if iGO is being loaded “on behalf of” another user.

To support the productized lookup fields mentioned above the AgentOne Agent permission set has been updated to provide read/write access to the following fields:

  • Insurance Case Object – Opportunity (AgentOne__InsuranceCase__c.AgentOne__Opportunity__c)
  • Opportunity Object – Insurance Case (Opportunity.AgentOne_Insurance_Case__c)
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Opportunity Integration, IGO Integration

Availability: Managed by iPipeline: Enabled for appropriate customers (based on functionality or license)

Implementation Steps
Coordinate with your AgentOne Implementation team to enable this feature

Optional:

Customization to specify a custom lookup field can be done via an Application Configuration setting with the introduction of the following setting:

Name Key Category Value
Case/Opportunity Integration Lookup IC.Opp.Integration.Lookup Opportunity Integration <custom lookup field>
How To Test
After confirming that the feature is enabled and that the iGO lightning component is added to the opportunity record home page…
1. Confirm that the org has public (read/write) as the OWD for accounts and opportunities
2. Create a new client and insurance case record owned by admin or a system user
3. Login as an agent user and create an opportunity owned by the agent user
4. Using the productized lookup fields link the insurance case (from step 2) to the opportunity (from step 3) and vice versa (the opporunity to the insurance case)
5. While using the lightning UX and logged in as the agent user open the opportunity from step 3 and load iGO via the lightning component
(either using Fiddler to capture the XML in the SSO to iGO or opening iGO via direct login as the iGO user associated to the opportunity owner confirm that the iGO case is created and opens for the iGO user associated to the opportunity owner instead of the client/insurance case record owner…)
Pre-fill from Opportunity Owner

​​​​​​Description: As an AgentOne user that is configured with Opportunity integration enabled, when there is an Opportunity linked to an Insurance Case, I would like to prefill the iGO case with the agent info from the opportunity owner instead of the insurance case owner.

Solution:
When starting a new iGO case from AgentOne and if Opportunity integration is enabled, then AgentOne will look for the existence of an Opportunity using the productized lookup fields (details of the productized lookup fields can be found in the release notes for Start IGO from Opportunity) and will send prefill info from the Opportunity owner (not the insurance case owner). This is in support of any prefill settings where the FROM ENTITY NAME = “OWNER”.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Opportunity Integration, IGO Integration

Availability: Managed by iPipeline: Enabled for appropriate customers (based on functionality or license)

Implementation Steps
Coordinate with your AgentOne Implementation team to enable this feature

How To Test
After confirming that the feature is enabled and that the iGO lightning component is added to the opportunity record home page…
1. Confirm that the org has public (read/write) as the OWD for accounts and opportunities
2. Create a new client and insurance case record owned by admin or a system user
3. Login as an agent user and create an opportunity owned by the agent user
    (make sure that you have some fields populated on the agent user that differ from the admin or system user that owns the client/insurance case – e.g. Agent Number, Default Issue State, Address)
4. Using the productized lookup fields link the insurance case (from step 2) to the opportunity (from step 3) and vice versa (the opporunity to the insurance case)
5. Make sure you have some prefill settings that prefill the selected field (see examples in step 3) where From Entity Name = “Owner”
6. While using the lightning UX and logged in as the agent user open the opportunity from step 3 and load iGO via the lightning component
(either using Fiddler to capture the XML in the SSO to iGO or by checking the fields on the iGO case confirm that prefill is passing the owner details associated to the opportunity owner instead of the client/insurance case record owner…)
Display Alerts for Opportunity Owner

​​​​​​Description:

As an AgentOne user with integration to opportunities and iGO case ownership is determined by the opportunity owner, I would like the alert that is received from iGO to be visible to the opportunity owner as opposed to the owner of the client/case.

Solution:

When opportunity integration is enabled and when the insurance case is linked to an opportunity for any alert sync record received when the alert is saved the owner of the alerts will be set with the opportunity owner.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Opportunity Integration, Alerts, iGO Integration, Pending Cases

Availability: Managed by iPipeline: Enabled for appropriate customers (based on functionality or license)

Implementation Steps
Coordinate with your AgentOne Implementation team to enable this feature

How To Test
After confirming that the feature is enabled and that the iGO lightning component is added to the opportunity record home page…
1. Confirm that the org has public (read/write) as the OWD for accounts and opportunities
2. Create a new client and insurance case record owned by admin or a system user
3. Login as an agent user and create an opportunity owned by the agent user
4. Using the productized lookup fields link the insurance case (from step 2) to the opportunity (from step 3) and vice versa (the opporunity to the insurance case)
5. While using the lightning UX and logged in as the agent user open the opportunity from step 3 and load iGO via the lightning component
6. Proceed through all screens and lock the case (sign the application and submit to agent to trigger an alert for the agent)
(after the alert sync record is received and processed open the alert to view the owner and confirm it is owned by the opportunity owner instead of the owner of the client/case… also confirm that the alert is visible to the opportunity owner via the alerts lightning component on the opportunity)
Transfer iGO Case when Opportunity Owner Changes

​​​​​​Description:As an AgentOne user that is configured with opportunity integration enabled, I would like the iGO case to be transferred when the Opportunity linked to the Insurance Case changes ownership, rather than when the account and insurance case changes ownership.

Solution:

In any org where opportunity integration is enabled, when changing owner on the Opportunity, AgentOne will look to the Opportunity to determine if it has an insurance case, and then transfer the associated iGO case from the original Opportunity owner to the new Opportunity owner.

Also, when changing ownership of the Account, AgentOne will include any cases where the Opportunities have had the ownership changed with the account.
(By default, changing ownership on the client through the wizard will update all opportunites that belong to the same owner.  If the logged in user has the ‘Transfer Records’ permission then that user is also presented with the option to include opportunites not owned by the client owner.)

The AgentOne transfer case logic will take the account transfer wizard into consideration and include the iGO cases for each opportunity determined to have a linked insurance case and where the opportunity owners have changed.

OBO (IGO on-behalf-of)

For any cases that failed to be updated during the transfer web service request, the existing fields on Insurance Case (External_User_Id_c and Transfer_Status_c) will be used to determine if we need to use OBO to open the iGO case and send over original owner details in the future.

For any orgs that do not have opportunity integration enabled AgentOne will continue to look at the client/case ownership to determine the “from” and “to” users when the iGO transfer web service request is made.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Opportunity Integration, IGO Integration

Availability: Managed by iPipeline: Enabled for appropriate customers (based on functionality or license)

Implementation Steps
None

How To Test
After confirming that the feature is enabled and that the iGO lightning component is added to the opportunity record home page…
1. Confirm that the org has public (read/write) as the OWD for accounts and opportunities
2. Create a new client and insurance case record owned by admin or a system user
3. Login as an agent user and create an opportunity owned by the agent user
4. Using the productized lookup fields link the insurance case (from step 2) to the opportunity (from step 3) and vice versa (the opporunity to the insurance case)
5. Repeat steps 3 and 4 above for another opp as well as for a 3rd opp that has the same owner as the client/IC record
6. Change owner on the opportunity currently owned by the agent user (confirm that on iGO the original case is transferred to the new opportunity owner)
7. Change the owner of the parent account and include opportunities owned by other users (confirm that on iGO the all cases are transferred to the new opportunity owner)
Change Alert Ownership when Opportunity Owner Changes

​​​​​​Description:  As an AgentOne user that is configured with opportunity integration enabled, I would like the alerts ownership to be changed when the “opportunity” linked to the insurance case changes ownership.

Solution:
A change in opportunity ownership will trigger the the alert ownership changes as well, so that the alerts maintain the appropriate owner.

When account ownership is changed then (like the iGO transfer ownership as part of the opportunity integration), AgentOne will check which of the related opportunities were updated.  If there are Insurance cases that have linked Opportunities where the owner is not changed, the related alerts of those Opportunities will not have their ownership updated.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality:Opportunity Integration, Alerts, iGO Integration, Pending Cases

Availability: Managed by iPipeline: Enabled for appropriate customers (based on functionality or license)

Implementation Steps
None

How To Test
After confirming that the feature is enabled and that the iGO lightning component is added to the opportunity record home page…
1. Confirm that the org has public (read/write) as the OWD for accounts and opportunities
2. Create a new client and insurance case record owned by admin or a system user
3. Login as an agent user and create an opportunity owned by the agent user
4. Using the productized lookup fields link the insurance case (from step 2) to the opportunity (from step 3) and vice versa (the opporunity to the insurance case)
5. Add alerts either from iGO sync or by cloning an alerts sync record (confirm alert owner is set with the opportunity owner)
6. Change owner on the opportunity currently owned by the agent user (confirm that all alerts change ownership to the new opportunity owner)
Pending Case with Opportunity Ownership

​​​​​​Description: As an agent user using AgentOne with Opportunity integration enabled, I want the system to update the opportunity owner and transfer of the iGO case to the new owner when the primary writing agent is changed by a case manager or underwriter in the new business and underwriting system (via a pending case feed).

Solution:
When a pending case feed is received, and the primary writing agent has changed from the previous writing agent on the case, AgentOne checks if Opportunity integration is enabled, and if the case being updated has an Opportunity.

If there is an Opportunity and the primary writing agent is changed. then AgentOne will:

  1. Change the Opportunity owner to the new primary writing agent.
  2. If the insurance case has an iGO case associated, trigger a web service request to transfer the iGO case.
  3. Update the primary writing agent on the insurance case.
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Opportunity Integration

Availability: Managed by iPipeline: Enabled for appropriate customers (based on functionality or license)

Implementation Steps
Coordinate with your AgentOne Implementation team to enable this feature
How To Test
After confirming that the feature is enabled and that the iGO lightning component is added to the opportunity record home page…
1. Confirm that the org has public (read/write) as the OWD for accounts and opportunities
2. Create a new client and insurance case record owned by admin or a system user
3. Login as an agent user and create an opportunity owned by the agent user
4. Using the productized lookup fields link the insurance case (from step 2) to the opportunity (from step 3) and vice versa (the opporunity to the insurance case)
5. While using the lightning UX and logged in as the agent user open the opportunity from step 3 and load iGO via the lightning component
6. Take the case all the way to submitted status
7. Trigger a pending case feed that will update the case and change the primary writing agent
8. Confirm that the opportunity owner is changed to the new agent and that the iGO case can still be opened
Support iGO Sync for iGO direct-to-consumer (DTC) randomly-generated single-use accounts (added July 25 2019)

​​​​​​Description: iGO DTC (Direct To Consumer) cases need to synchronize to AgentOne.  iGO DTC cases are created and owned by a single-use “randomly” generated iGO user that does not and will not exist in the AgentOne system.

Solution:

AgentOne introduced support for synchronization of DTC cases (originating outside of AgentOne) by introducing a new Application Configuration setting for allowing iGO sync of DTC cases. (Similar to the other settings we previously introduced for CONNECTED, DISCONNECTED, MOBILE, etc.)
AgentOne introduced a setting that allows identification of a “Generic” DTC user in AgentOne needed to support DTC cases.  The DTC cases owned by the randomly generated iGO users will be mapped to the specified “Generic” user in AgentOne.
AgentOne saves the randomly created iGO user with the Insurance Case, as well as an indicator that the case is a DTC case.  This will be used to determine the actual iGO user, to be used as the FromID in a transfer VPS web service request when transferring the case, and to disallow opening iGO for DTC cases.
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: IGO Integration

Availability: Optional

Implementation Steps
AgentOne (enable DTC sync):
1. Log in as an administrative user
2. Go to Application Configuration from AgentOne Administration
3. Enable synchronization of DTC cases
​NAME ​KEY ​CATEGORY ​VALUE
​Allow iGO Sync Cases in DTC ​Allow.iGO.Sync.DTC ​AllowSync TRUE
AgentOne (create and setup the “generic” user):
1. Login as an administrative user

2. Go to Setup > Manage Users and create the user that will be used as the “generic” user for DTC cases (owned by randomly ​generated users)

  • The user to be specified as “generic” AgentOne user is required to have the following:
    • ​AgentOne Agent permission set
    • AgentOne Agent profile
    • ‘Is AgentOne’ field enabled
    • ‘iPipeline User ID’ field populated (does not need to be an existing iGO user) — this is the value you will need to add to the app config setting in step 4
    • ‘Agent Number’ field populated (does not need to be a valid iGO agent number)
3. Go to Application Configuration from AgentOne Administration
4. Edit the setting ‘Random iGO to AgentOne Generic User’ by setting the iPipeline User ID of the user from step 2
​NAME KEY​ CATEGORY​ VALUE​
Random iGO To Generic AgentOne User​ ​Random.iGO.Generic.AgentOne.User ​GenericUser ​<the ipipeline user id specified on the user from step 2>
How to Test

1. Create a DTC case on iGO

2. Confirm the case is synchronized to AgentOne and that the sync record is processed and saved in AgentOne against the generic user.  i.e  Confirm the IC has the ‘igo_case_owned_by_random_user__c’ set to true AND the ‘iGO_user__c’ set with the randomly generated igo user.

3. Open the Insurance Case record and attempt to open the iGO case (confirm that iGO will not open because it is owned by a “randomly” generated iGO user)

3. Trigger the iGO VPS transfer by changing the opportunity owner (if opp integration is on) OR the client owner (if opp integration is off)

4. Using system jobs while logged in as admin, confirm that the transfer sends the randomly generated iGO user in the FROMID of the transfer case request

iGO Originated Cases – match agent on LogonID

​​​​​​Description: The ‘OriginatingUserLogonID ‘ in iGO has been confirmed to maintain the original iGO user (even after a case is transferred to another iGO user)… this will negatively impacts synchronization of cases transferred to another agent because our matching logic determines the matching AgentOne agent from ‘OriginatingUserLogonID’ therefore any transferred iGO cases will be inaccurately saved against the original case owner.

Solution:Update to ESB on sync from iGO to always include the iGO LogonID (determined from the ‘ParentEntityID’ in iGO which always reflects the current iGO case owner) and introduce the new field on the Insurance Case object and a sync mapper setting to populate it with the iGO LogonID and change the AgentOne agent matching logic to use the ‘LogonID’ instead of ‘OriginatingUserLogonID’ to match against the iPipeline User ID.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: IGO Integration

Availability: Automatic

Implementation Steps

None

How to Test
  1. Login as an agent user and create a new client with First Name, Last Name, and Birthdate then start iGO (this step is to create the SSO login)
  2. Open a new tab in the same browser session and load iGO (direct log in… “CONNECTED”)
  3. Create a new case and enter the same First Name, Last Name, and Birthdate that will match the client created in step 1
  4. After you trigger a sync to AgentOne confirm ​that the insurance case is saved to the agent from step 1 and has the user from step 1 saved to the ‘iGO User’ {iGO_User__c) field
  5. From iGO direct login transfer the case to another agentone user and trigger the sync back to AgentOne
  6. After the sync to AgentOne confirm ​that the insurance case is saved to the agent from step 5 and has the user from step 5 saved to the ‘iGO User’ {iGO_User__c) field
Include GAID with Cases Originated in iGO

​​​​​​Description:  When trying to open a case where the iGO GAID (aka subcompany ID) of the user does not match the GAID in which the iGO case was created with, the error displayed within the iGO canvas frame was cryptic and unhelpful.

Solution:

Created a new field, Originating User Subcompany ID, to store the GAID from which the iGO case was created and use it to display a more helpful message.  If a user with a different GAID tries to open the case, the following error message will appear instead of iGO:  “The iGO Case is not accessible.  The Originating User SubCompany ID of 6643 on the Insurance Case is different than the GAID in Use of 6613 of the logged in User.  If this is unexpected, please contact your AgentOne Help Desk or System Administrator.”​

On mobile or Lightning Experience with the iGO Lightning component, the new error message will be displayed instead of attempting to open iGO.  On Classic Experience, the Insurance Case insurance tools Open Application button will be disabled if the GAID of the current user does not match the GAID of the case.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: IGO Integration

Availability: Automatic

Implementation Steps
N/A

How To Test

1. Login as User A and Create an iGO case and note the GAID of the user creating that case.

2. Now find a user  (User B) with different GAID settings and that would have permission to see the insurance case created in step 1.

3. Login as User B and try to open the case.

4. Confirm that you see an error message as documented above.

Promote LogonID and OriginatingUserSubcompanyID from JSON to fields on the Sync Object

​​​​​​Description:  Three new fields that are useful for iGO sync back were added to the Sync JSON.  If the values are useful to be able to search on it for troubleshooting, the values needs to be stored in a field that can be searched.

Solution:

Added LogonId and OriginatingUserSubCompanyId to the Tags field of the Sync record.

For iGO InsuranceApp (EntityType) sync back, retrieve the following node values from the Data field JSON and add it to the tags field in the name value format

   1. originatingusersubcompanyid  (OrigSubId),
   2. originatinguserlogonid (PWA),
   3. originalmodeofapplication (OrigModeApp)
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Sync Records

Availability: Automatic

Implementation Steps
N/A

How To Test
1. Sync back an iGO update.
2. Open the Log record created from the iGO sync.  You can search for the corresponding log record by searching the messagetrackingid on the sync record.
3. Con​firm that you see the Tags field populated as documented above.
Update Coverage Amount Mapping in Pending Case feed

​​​​​​Description:  AgentOne Pending Case Feeds now have updated mappings for coverage amount fields on the Insurance Case and the related Coverage object.  The Insurance Case Coverage field in AgentOne is mapped to ACORD fields intended for base policy face amount for life insurance products.  AgentOne will now also support the base policy face amount (ACORD Life/FaceAmt) if it’s available.  Total Coverage Amount (ACORD Life/DeathBenefitAmt) is also a very important field to map, so it is now mapped to a new Insurance Case field for Total Coverage Amount.  New mappings were also added for the applied for (initial) coverage amount, and the current coverage amount is now mapped from the appropriate ACORD field.

Solution:
Reviewed and updated Coverage Amount field mappings. as follows:

1. InsuranceCase__c – Total_Coverage_Amount___c = Acord Life\DeathBenefitAmt
This is a new field on the Insurance Case with August 2019

2. InsuranceCase__c  _ – CoverageAmount__c =

         If (TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/FaceAmt) has value

         then

              map (TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/FaceAmt)

         Else if (TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage(@TC=1 for Base)/CurrentAmt) has value

               map TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage(@TC=1 for Base)/CurrentAmt

         Else

               map TXLife/TXLifeRequest/OLifE/Holding/Policy/Life/Coverage(@TC=1 for Base)/InitCovAmt

3. Coverage__c  – Coverage_Amount__c = Life/Coverage/CurrentAmt

4. InsuranceCase__c  _ – Applied_For_Coverage_Amount__c = Life/Coverage[Base]/InitCovAmt

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Pending Cases

Availability: Automatic

Implementation Steps
For customers who want to display the new total coverage amount field, add Total Coverage Amount to your Insurance Case page layouts.

How To Test
1. Use/Manipulate an Acord file to include the above Acord field values.
2. Send to AgentOne FTP.
3. Once the ACORD file is processed, confirm that the Coverage amount is mapped to the fields specified above.
Use more meaningful file names for Illustration PDFs

​​​​​​Description:  Illustration PDFs synched back from iGO had cryptic file names, so users were forced to open each individual file to find the one they were looking for.

Solution:
Updated the Illustration PDF name to have the following format <product_name>_<coverage_amount><primary insured last name><datetimestamp>.PDF

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Illustrations Integration

Availability: Automatic

Implementation Steps
N/A

How To Test
1. Create a new insurance case or an existing insurance case to launch into iGO Illustrations.
2. Run an Illustrations in iGO and Save it or click Send to CRM to send it to AgentOne.
3. Open the Illustrations record in AgentOne and confirm that the name of the attached PDF is formatted as <product_name>_<coverage_amount><primary insured last name><datetimestamp>.PDF
Fact Finder – Disable Use of Object

​​​​​​Description: Fact Finder records were being created each time a Client (Account) record was created, whether or not the implementation was leveraging it.  iGO sync backs were also set to update the Fact Finder object.  However, this object is not being used by any current AgentOne customer, so the added overhead of creating the records for each Client utilized resources unnecessarily.

Solution:
Discontinue creating a Fact Finder record (associated to Contact) each time a Contact record is created.  Existing FactFinder records will not be deleted by AgentOne, but customers are encouraged to do so to reduce impacts to Data Storage Limits.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Customer Centricity

Availability: Automatic

Implementation Steps
N/A

How To Test
1. Create a new Account record.
2. Confirm that a corresponding Fact Finder record is not created.
Upgrade AgentOne for orgs set to Public OWD for Clients (Accounts)

​​​​​​Description:  Customers want to install and upgrade AgentOne when the Org Wide Default setting for Account is set to Public, rather than Private.

Solution:
Removed any and all AgentOne code that was previously enforcing a private sharing model for Accounts.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality:  Call Center Support, Customer Centricity

Availability: Automatic

Implementation Steps

N/A

How To Test
  1. Set OWD of Account to Public
  2. Upgrade to AgentOne version 12.8 or later
  3. Confirm it is successfully upgraded.
Default New User Alerts Rules from Global Alert Types Settings

​​​​​​Description: As a new AgentOne user, I want my Alerts to behave in the manner that my administrator has configured as the org-wide default, so that alerts will be prioritized and displayed according to what my corporation defines. I then want to be able to change my Alert Rules from the org-wide defaults defined by my administrator so that I can define my own logic.

Solution:

When the user that the alert is for doesn’t have the user-level ‘Alert Rules’ settings AgentOne will look to the org-wide default settings configured under ‘Alert Types’ applying those settings to the alerts that are being generated. Once the user accesses the user-level ‘Alert Rules’ page all future alerts received for the given user will follow the the user-level settings from ‘Alert Rules’.
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality:  Alerts

Availability: Automatic

Implementation Steps

N/A

How To Test
  1. Login as an administrative user and go to Alert Types then configure the ‘Default Action’ for each alert type (e.g. set the ‘Expired Signature’ alert type to Dismiss)
  2. Create a new user (or test using one that is known to have never accessed the user-level ‘Alert Rules’ page)
  3. Trigger the creation of an alert for the user in step 2 (making sure it is for the alert types configured in step 1)
  4. Confirm that when the alert is generated from the sync record that it has the priority and/or is dismissed in accordance with how the alert type is configured
  5. Login as the user from step 2 and open the Alert Rules page (confirm that it inherited the default settings from the global Alert Types page)
  6. Change the default action for a given alert type under the users ‘Alert Rules’ page
  7. Trigger another alert for the user from step 6 and confirm that it now respects the user-level settings from the users Alert Rules

Fixes

Service API Retrieve returns wrong datetime format

​​​​​​Description:

We are trying to update the name field of one of the insurance case which has an igo eapp associated with it by using the AgentOne Service Api “updateEntity” method and it is throwing an error.
Error received after running the above code in anonymous block–> System.TypeException: Invalid date/time: 2018-12-03T17:24:36.000Z

Solution:

The previous timezone returned on ‘Retrieve’ is zulu.  Updated it to return GMT by converting ‘Z’ to GMT.  Updated date-format from ‘yyyy-MM-dd\’T\’HH:mm:ss.SSS\’Z\” to ‘yyyy-MM-dd HH:mm:ss’

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality:  AgentOne Service API

Availability: Automatic

Implementation Steps

n/a

How To Test
Open DevConsole and run the following script below and confirm that you do not get an error.
AgentOne.OrganizationService service =new AgentOne.OrganizationService();
Id csId = Id.valueOf(‘a1N110000042NnvEAE’);
AgentOne.InsuranceCaseEntry cs = (AgentOne.InsuranceCaseEntry)service.retrieveEntity(csId);
cs.setFieldValue(AgentOne_InsuranceCase_c.Name,’Name Updated Insurance Case’);
service.updateEntity(cs);​

 

Salesforce Summer ’19 Sync Search Page- actions don’t work

​​​​​​Description: After the Salesforce Summer ’19 release, in Lightning Experience only, no info is displayed when clicking on [View JSONs] and [Compare Selected Sync Records] buttons on the AgentOne Sync Search page.

Solution: View JSON and Compare Selected Sync Records loads a Visual Force page.  It was trying to load a record but was not passed the record ID.  It is unclear why the record ID was not required to be passed, and that it worked pre-Summer ’19, but it seems it is needed when added to a Lightning page to be displayed in Lightning Experience.    

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Admin

Availability: Automatic

Implementation Steps

n/a

How To Test

Make sure you are in Lightning Experience.

1. Add the Sync Search Visual Force page somewhere on a Lightning page.
2. Open page with Sync Search embedded.
3. Enter any value for search that will return a results.
4. In displayed results, click on any of the buttons: [View JSONs] or [Compare Selected Sync Records]​.
5. Verify info opened in separate tab​.​
Revise Illustration Drop-Down Displays all Insurance Tools Regardless of Product Type

​​​​​​Description: Revise Illustration button drop down displays all illustration tools regardless of product type​.

Solution:  AgentOne was not checking for the Insurance tool and Product Type, in order to display the correct tools under the Revise Illustration button AgentOne has been updated to check the  ‘Illustration tool’ and the ‘Product Type’ saved against the Insurance Case.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Illustrations Integration

Availability: Automatic for customers with Issued Other Than Applied feature enabled

Implementation Steps

n/a

How To Test
  1. Ensure the org has feature parameter AgentOne__IssuedOtherThanApplied enabled.
  2. Configure multiple tools for Illustration including a tool that should not be loaded. ie.  an illustration tool for Annuity Product Line of Business.
  3. Ensure you have an Illustration Tool configured for Life Line of Business.
  4. Find an open a case in Delivery Status with a product type belonging to Life Line Of Business.
  5. Confirm that you see the Revise Illustration button.​
  6. Confirm that you do not see any Illustration tools that are not configured for the Life Line of Business, and confirm that you do not see duplicates of tools.
Salesforce Governor Limits Exceeded

​​​​​​Description:

Some customers are seeing the following error in their logs
 Developer script exception from xxx : ‘AgentOne.BackgroundSyncWorker’ for job id ‘7072S00007xLXvh’ : AgentOne:Too many query rows: 50001
 ExtendedMessage: Apex script unhandled exception by user/organization: 00544000009csQp/00DE0000000anft
  Failed to process batch for class ‘AgentOne.BackgroundSyncWorker’ for job id ‘7072S00007xLXvh’
  caused by: System.LimitException: AgentOne:Too many query rows: 50001
  Class.AgentOne.BackgroundSyncWorker.execute: line 114, column 1​

Solution:

An issue was isolated to an high volume of records (over 50000) being retrieved from the Users object based on Agent Number. An assumption has been made that this behavior is taking place due to a large volume of User records sharing the same Agent Number (most likely blank).
Updated the query to retrieve agents by their agent number to filter out inactive user records and users that are not AgentOne users. This is expected to minimize the number of records returned in the query, thus removing the governor limit error. A CPU timeout error appears to be related, however, further testing is strongly recommended to confirm.
​​​​​Risk Analysis: Medium

Affects which Features / Functionality:  Underwriting Requirements and Alerts

Availability: Automatic

Implementation Steps

n/a

How To Test
Continue to process Pending Case Sync as usual with the same number of users on the system.  Confirm the error no longer appears.
Fix Default Pre-fill Settings that Pre-fill Owner to User Data in iGO

​​​​​​Description:

The AgentOne default prefill settings that prefill from the user’s Agency Number (agency_number__c) to the iGO <UserData> section were prefilling from the insurance case “Owner”.  When opening a case that belongs to another user there is no guarantee that the logged in user and OBO user have the same Agency Number and since all prefill settings that prefill to UserData on iGO will always update the iGO logon user not the OBO user, this could inadvertently update the iGO login user with agency number of the case owner when opening a case on-behalf of another user.

Solution:

The following “default” AgentOne prefill settings for ‘Agency_Number__c’ have been changed to prefill from “Login User” instead of “Owner”.
  • UD_AGY_CarrAppt_CompanyProducerID​
  • UD_AGY_CarrAppt_CompanyProducerID_Ill​​
​​​​​Risk Analysis: Low

Affects which Features / Functionality:  IGO Integration, Illustrations Integration

Availability: Automatic

Implementation Steps

n/a

How To Test
  1. Update a user (e.g. Alan Agent) with agency number “abc123”
  2. Update another user (e.g. Anna Agent) with agency number “xyz789”
  3. Login as Anna Agent and open a client that is owned by Alan Agent
  4. While logged in as Anna Agent start iGO for the client owned by Alan Agent (using OBO)
  5. Capture the SSO and view XML via fiddler to see that although the case is owned by Alan Agent it prefills agency number from the logged in user with “xyz789” to <UserData> section of the XML
Mixed DML Operation Error  (added Aug 1 2019)

​​​​​​Description:  A customer’s nightly user update process failed with DML exception error.

Solution:  AgentOne had error logging code that would fire if the user was not an AgentOne user.  If not, it would attempt to write this error to the AgentOne Log object.  After writing to the Log object, the DML (Salesforce Data Manipulation Language) exception would fire because it is not permissible to update a User object followed by a custom object.  The logging was removed since it created extra noise in the Log file for non-Agentone users, and it was not deemed helpful.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Error Handling

Availability: Automatic

Implementation Steps

n/a

How To Test
Customers who previously experienced this issue should attempt to load the User data with the same user to ensure that the Is AgentOne flag is not checked on the User record.
Confirm that the file imports successfully.

Profile and Permission Set Changes

The​ following changes have been made to AgentOne permissions with the August 2019 release.

How to use this Info​​​​​
  • It is highly recommended that going forward that all AgentOne customers use permission sets to assign AgentOne permissions to their users.
  • All new implementations should rely on Permission sets as the primary means of assigning AgentOne permissions.
  • We continue to support orgs that do not currently use permission sets by documenting all the permission changes here in the release notes.
  • If you are not using the out of the box AgentOne Agent Permission set, then please reference the below changes to manually apply it to your cloned Permission Set or Profile as needed, following the respective AgentOne upgrade to the org.
​IMPORTANT: If your org is updated via Push Upgrade, then your Profiles will not get updated. Push upgrades do not give iPipeline the option to select Profiles to copy permissions to. If you are still relying on Profiles, then you will need to manually make Permissions changes to your Profiles. ​
AgentOne Agent Profile
  • Insurance Case Object – Total Coverage Amount ( total_coverage_amount__c) – added read access
    • ​Reason: New fields for Insurance Case – Add Total Coverage Amount
  • Insurance Case Object – iPipeline Tracking Id ( iPipelineTrackingId__c) – added read access
    • ​Reason: New fields for Support Additional fields for integration with iGO & Resonant
  • Insurance Case Object – iPipeline Tracking Scenario Id (iPipelineTrackingScenarioId__c​) – added read access
    • ​Reason: New fields for Support Additional fields for integration with iGO & Resonant​​
  • ​​Insurance Case Object – Opportunity (AgentOne__Opportunity__c) – added read/write access
    • Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO
  • Opportunity – Insurance Case (AgentOne__Insurance_Case__c) – added read/write access
    • Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO​
  • ​​Insurance Case Object – iGO User (iGO_User__c) – added read access
    • Reason: New field for Change to agent matching logic for iGO originated cases use ‘LogonID’ instead of ‘OriginatingUserLogonID’​
AgentOne Agent Permission Set
  • Insurance Case Object – Total Coverage Amount ( total_coverage_amount__c) – added read access
    • ​Reason: New fields for Insurance Case – Add Total Coverage Amount
  • Insurance Case Object – iPipeline Tracking Id ( iPipelineTrackingId__c) – added read access
    • ​Reason: New fields for Support Additional fields for integration with iGO & Resonant
  • Insurance Case Object – iPipeline Tracking Scenario Id (iPipelineTrackingScenarioId__c​) – added read access
    • ​​Reason: New fields for Support Additional fields for integration with iGO & Resonant​​
  • ​​Insurance Case Object – Opportunity (AgentOne__Opportunity__c) – added read/write access
    • Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO
  • Opportunity – Insurance Case (AgentOne__Insurance_Case__c) – added read/write access
    • ​Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO​
  • Insurance Case Object – iGO User (iGO_User__c) – added read access
    • Reason: New field for Change to agent matching logic for iGO originated cases use ‘LogonID’ instead of ‘OriginatingUserLogonID’​
AgentOne Admin Permission Set
  • Insurance Case Object – Total Coverage Amount ( total_coverage_amount__c) – added edit access
    • ​Reason: New fields for Insurance Case – Add Total Coverage Amount
  • Sync Object – Make Tab available for permission set
    • Reason: dd Sync and Log tab to AgentOne Admin and AgentOne Support Permission set​​
  • Log Object – Make Tab available for permission set
    • Reason: Add Sync and Log tab to AgentOne Admin and AgentOne Support Permission set​​​​
  • ​Insurance Case Object – iPipeline Tracking Id ( iPipelineTrackingId__c) – added edit access
    • ​Reason: New fields for Support Additional fields for integration with iGO & Resonant​
  • Insurance Case Object – iPipeline Tracking Scenario Id (iPipelineTrackingScenarioId__c​) – added edit access​​​
    • ​Reason: New fields for Support Additional fields for integration with iGO & Resonant​
  • ​​Insurance Case Object – Opportunity (AgentOne__Opportunity__c) – added read/write access
    • Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO
  • ​Opportunity – Insurance Case (AgentOne__Insurance_Case__c) – added read/write access
    • ​Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO​
  • ​​Insurance Case Object – iGO User (iGO_User__c) – added read/write access
    • Reason: New field for Change to agent matching logic for iGO originated cases use ‘LogonID’ instead of ‘OriginatingUserLogonID’​​
AgentOne Support Permission Set
  • Insurance Case Object – Total Coverage Amount ( total_coverage_amount__c) – added edit access
    • ​Reason: New fields for Insurance Case – Add Total Coverage Amount​
  • Sync Object – Make Tab available for permission set
    • ​Reason: Add Sync and Log tab to AgentOne Admin and AgentOne Support Permission set​​
  • ​Log Object – Make Tab available for permission set​
    • Reason: Add Sync and Log tab to AgentOne Admin and AgentOne Support Permission set​​​​
  • ​​Insurance Case Object – Opportunity (AgentOne__Opportunity__c) – added read/write access
    • ​Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO
  • Opportunity – Insurance Case (AgentOne__Insurance_Case__c) – added read/write access
    • ​​Reason: New fields for Start iGO from opportunity and use case owner from opportunity owner in SSO​​
AgentOne Tabs Permission Set - New!
  • None

 

1 Comments
  • Brenda Higgs says:

    Nice job Product Team

    July 24, 2019 at 9:18 am
Leave A Comment