AgentOne Release Notes

AgentOne January 2020 Release Notes

UAT Release Group 1: Jan 8, 2020 ~noon ET
UAT Release Group 2: Jan 15, 2020 ~noon ET
Production Release: Jan 17, 2020  ~10:00pm ET

version 15.x

Enhancements

AgentOne Quick Start Lightning Component – UI update

​​​​​​Description:

The iPipeline User Experience team recommended changes to the AgentOne Quick Start component, to better match the Opportunity record homepage when triggering the Start/Open iGO lightning component.

Solution:

User interface changes to the component include:
  • Header color change (previously green)
  • Background (white)
  • Font/spacing/formatting
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Quick Start Component

Availability: Automatic

Implementation Steps

None

How To Test
  1. Ensure Quick Start component is loading and saving correctly.​
Aura Components in UI namespace being retired in Salesforce Summer ’21

​​​​​​Description: Salesforce is deprecating Aura components in the UI namespace in Summer ’21.  AgentOne is now using similar components in the Lightning namespace instead, as recommended by Salesforce in the Winter ’20 Release Notes here  https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_aura_ui_deprecate.htm​.

Solution:

All the UI tags are replaced with Lightning tags.  Removed unwanted CSS classes around UI elements and changed some js files based on tag changes.  Changed press to onclick for lightning:button.

​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: AgentOne Admin App,  AgentOne Lightning Components , Quick Start Component

Availability: Automatic

Implementation Steps

None

How To Test
  1. Confirm no errors in AgentOne Admin App for regular operations of creating, updating and saving settings.
  2. Confirm no errors occur where using the AgentOne Lightning IGO and AgentOne Quick Start Lightning Components

Enhancement and Fixes – enable by March 2020 release

Pending Case Alerts – move business logic to Salesforce

​​​​​​Description:  

AgentOne pending case alerts are currently generated via business logic in the AgentOne data layer.  In order to address timing issues and extraneous (many false) sync errors between the data layer queues, source applications and Salesforce, the pending case alerts business logic has been moved to Salesforce.
Since the Pending Case processing and Pending case Alerts processing were separate disjointed processes, the pending case alert did not know when pending case processing was complete.

Solution:

Migrate the Pending Case Alerts logic from the AgentOne data integration layer into Salesforce, as Processes and Flows.  This alternative implementation is only leveraged for orgs that have it enabled by iPipeline.  The flow will be installed as active, but the first check is to ensure that this feature is enabled.  If it is not enabled, the flow will exit immediately.

Three Flows were created as templates, and packaged as active flows:

  • Create Requirement Received Alert
    • Proceed only if Requirement is for an Agent, and that requirement isn’t in approvedcompleted, or cancelled status.
    • Proceed if a similar active alert doesn’t already exist and if not, then create an alert.
  • Handle Pending Case Alerts  (status changes)
    • Proceed only if the Insurance Case is Active.
    • Proceed If the Insurance Case status is in 1) Issued & Ready for Delivery, or 2) Delivered, or 3) Concluded status.
    • Proceed only if the active alert doesn’t already exist.
    • Dismiss all alerts associated with the Insurance Case.
    • Check if there is an existing dismissed alert.  If so, update it to active (non-dismissed) and change alert creation time to now.   Otherwise create new alert.
  • Create Logs for Flows (Create_Logs_for_Flows)
    • Called by the first 2 flows to log flow error handling

Two Processes created as templates, and packaged as active flows:

  • Create Requirements Alerts
    • triggers the Create Requirement Received Alert Flow upon Create of Requirement
  • Insurance Case Record Create or Update
    • triggers the Handle Pending Case Alerts Flow ​

The flows will call custom code to Create and Dismiss Alerts while respecting Alert Rules.

​This enhancement will require more significant validation testing than most low-risk features included in the monthly AgentOne release.  Consequently, it will be delivered but disabled for all orgs with the January 2020 release.  Customers and implementation teams can begin testing with the feature enabled as soon as Jan 22, and choose when to enable it on production orgs, anytime on or before the AgentOne March 2020 release.  This flexible window essentially provides two months for customer-specific UAT regression testing for any pending case alert generation that is identified.     ​
​​​​Risk Analysis: Low for Jan 2020 while disabled; Medium when enabled

Affects which Features / Functionality: Alerts, Pending Case Status and Alerts

Availability: Required testing and coordination steps, before March 2020 release

Implementation Steps
  1. This step can be done anytime after the January 2020 managed package (v15.x) is installed on the org (i.e. UAT or PROD push upgrade), and must be done on production orgs before the deadline (i.e. March 2020 Prod release date).  This step alone will not enable the feature unless step 2 is done.  In the org,
    • Confirm the following Flows are active:
      • ​Create requirement Received Alert​
      • Handle Pending Case Alerts
      • Create Logs for FLow (Create_Logs_for_Flows)
    • Confirm the following Process builders are active:
      • Create Requirements Alerts
      • Insurance Case Record Create or Update
  2. Coordinate with iPipeline to enable the Create Pending Case Alerts​ Feature Parameter for the specified org, at the desired day and time on or before the deadline. (i.e. March 2020 Prod release date)
  3. Coordinate with iPipeline to disable Pending Case Alerts in the AgentOne data layer, at the same day and time as Step 2.
How To Test
  1. Run all tests that create Pending Case Alerts in an org with the old data layer method.
  2. Enable and repeat tests.
  3. Confirm that alerts creation and dismissal behavior ​are the same (other than noted exceptions).
Pending Case Status Alerts were only created once per unique status

​​​​​​Description:  AgentOne should create the alert again if there is currently no active alert for Issued and Ready for Delivery, Concluded, or Delivered and the Insurance Case reaches that same status on a subsequent status update.

Solution:

Change the check for existing alerts to search only active alerts.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Alerts, Pending Case Status and Alerts

Availability: See Pending Case Alerts – Move Business Logic to Salesforce

How To Test
  1.  Update a Policy to a Concluded status type like status_code = 7.
  2. Confirm that there is an active alert for Pending Case in Concluded status.​
  3. Update a Policy to a Delivered status type like status_code = 1
  4. Confirm that the Pending Alert for Concluded status type is dismissed.
  5. Update a Policy to a Concluded status type like status_code = 7.
  6. Confirm that there is an active alert for Pending Case in Concluded status.
New requirements for a delivered or concluded case were automatically dismissed 

​​​​​​Description: New requirements that came with a concluded or delivered status were inadvertently dismissed immediately because the previous business logic dismissed all previous alerts, and the new alert was not distinguished from the previous alerts.

Scenario:

Update for Policy 123 comes to AgentOne:  Policy Number 123 comes in with pending or issued status.

  • New Req A
  • New Req B

Actual behavior:  Alert for Req A and B is created.

Second Update for Policy 123:  Policy Number 123 comes in with delivered or concluded status, with a new requirement.

  • Update Req A
  • Update Req B
  • New Req C

Actual Behavior:  Alert for Req C is created.  Alerts for Req A, B and C are all dismissed.

Expected Behavior: Only alerts for Req A and B should get dismissed, and alert for Req C should be active (show alert = true).

Solution:

The action to dismiss previous alerts will occur first, then create any new alerts that were not previously created.  New requirements are identified by requirements that did not have a matching ExternalID already in the system.  ExternalID is the RequirementUniqueInfoID for the related Case Requirement.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Alerts, Pending Case Status and Alerts

Availability: See Pending Case Alerts – Move Business Logic to Salesforce

How To Test
  1. Test with an ACORD file for a Policy that is a delivered or concluded Status type, but has a requirement with a new RequirementInfoUniqueID​.
  2. Sync it to AgentOne and confirm that the alert for the Case Requirement is created and displayed.​
New requirements for an issued case were automatically dismissed 

​​​​​​Description:Any time a new requirement is received from a pending case feed where the responsible party is the primary writing agent, the related Alert should also be created when the Case Requirement is created. Previously, this was working properly when the insurance case was not already issued, but if the case was already issued then the associated alert was not being generated.

Solution:

The action to dismiss previous alerts will occur first, then create any new alerts that were not previously created.  New requirements are identified by requirements that did not have a matching ExternalID already in the system.  ExternalID is the RequirementUniqueInfoID for the related Case Requirement.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Alerts, Pending Case Status and Alerts

Availability: See Pending Case Alerts – Move Business Logic to Salesforce

How To Test
  1. Test with an ACORD file for a Policy that is an issued not paid status, but has a requirement with a brand new RequirementInfoUniqueID​.
  2. Sync it to AgentOne and confirm that the requirement is created.

Profile and Permission Set Changes

The​ following changes have been made to AgentOne permissions with the January 2020 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
  • Added permissions to ReviseIllustratonController class
    • ​Reason: Revise Illustration for Insurance Tools LWC
  • ​Added permissions to CopyInsuranceCaseAura​​ class
    • ​Reason: Insurance Tool Lightning Component for Copy Insurance Case
AgentOne Agent Permission Set
  • Added permissions to ReviseIllustratonController class
    • ​Reason: Revise Illustration for Insurance Tools LWC
  • ​Added permissions to CopyInsuranceCaseAura​​ class
    • ​Reason: Insurance Tool Lightning Component for Copy Insurance Case
AgentOne Admin Permission Set
  • None
AgentOne Support Permission Set
  • None
AgentOne Tabs Permission Set
  • None

 

 

 

Leave A Comment