AgentOne Release Notes

AgentOne July 2020 Release Notes

UAT Release: July 15, 2020 ~noon ET
Production Release: July 24, 2020  ~10:00pm ET
version 20.x

The contents of the release notes are directed to orgs that are being upgraded directly from the immediate previous release of AgentOne to this new release of AgentOne.  For more details or for complete information for a new implementation, refer to the AgentOne Implementation Guide.

Features

Support for Salesforce Shield Platform Encryption

Updated:  Added feature July 21

​​​​​​Description:

AgentOne customers are increasingly choosing to increase their data security by using the Salesforce Shield Platform Encryption feature for compliance and encryption. They are electing to encrypt a variety of widely used standard and custom fields, especially those that represent protected personally identifiable information (PII) and personal health information (PHI) of their clients. The AgentOne product needs to support likely applications of Platform Encryption.

Solution:
  • Changed queries to dynamic so that probabilistic encryption can be supported if not used in matching logic for insurance cases and clients.​
  • Modify code referencing Account.Name so that if it’s encrypted, it will use SOSL. Otherwise, SOQL which uses WHERE and LIKE operator will be used.

The below are the list of PII fields that need to be considered in the AgentOne product for encryption schemes. Only fields on this list have limitations or constraints. If it’s not on this list, it means that considering that field in encryption can be done without considering AgentOne base product impacts.

Field Supported Encryption
Account.Name, (Person Account org includes Account.LastName, Account.Firstname, Contact.Name) Probabilistic if not used for matching.
Deterministic if used in Matching
Account.Legal_First_Name__c Probabilistic if not used for matching.
Deterministic if used in Matching
Account.Phone Probabilistic if not used for matching.
Deterministic if used in Matching
Account.Email Probabilistic
Account.Hashed_Tax_Id__c Deterministic
Contact.Hashed_Tax_Id__c Probabilistic if not used for matching.
Deterministic (Only Case-Insensitive) if used in Matching
Contact.External_Id__c Deterministic (Only Case-Insensitive)
Contact.FormerSurnames__c Probabilistic
Contact.Finserv_Tax_Id__c Probabilistic
InsuranceCase__c.Policy_Number__c Deterministic
InsuranceCase__c.External_Id2__c Deterministic (Only Case-Insensitive)
User.Hashed_SSN_Tax_id__c Deterministic(Only Case-Insensitive)

​​​​​Risk Analysis:
Medium

Affects which Fea​tures / Functionality:  Quick Start Component, iGO Integration, Pending Case Feeds, Lookups on Admin page

Availability: Automatic

Implementation Steps

Obtain and enable Salesforce Shield Platform Encryption licenses from Salesforce.

How To Test

Validate that matching logic still works with Probabilistic Encryption without errors.

  1. In an org that has Platform Encryption enabled.
  2. Choose a field that is used in your contact matching logic like Contact.Hashed_Tax_Id__c and set it to Deterministic Case Insensitive Encryption.
  3. Sync a new record to AgentOne that has a value for Contact.Hashed_Tax_Id__c.
  4. Confirm that it is attempting to match on that field and that there is no sync errors related to Contact.Hashed_Tax_Id__c.
  5. Confirm that it is correctly matching the Contact if there exists a Contact in the system that matches the one in the sync record.
Coverages Lightning Component
​​​​​​Description:

AgentOne Lightning Component – Coverages / Riders

Solution:

The AgentOne – Related Coverage Lightning Component displays the related coverages of a specific Insurance Case on Lightning (including Financial Services Cloud) or mobile experience. Like the AgentOne iGO and other custom AgentOne Lightning components, this component is intended to be used on the Insurance Case record home page, the Opportunity record home page, or on any object’s record home page if it has a lookup (1:1) relationship to an Insurance Case.​

For each coverage associated with Insurance related to the displayed record, the component includes the base coverage indicator (graphical), product name, coverage amount, covered insured name (if different from primary insured), the annualized premium.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Lightning Components

Availability: Optional

Implementation Steps
  1. Add AgentOne – Coverages component to Opportunity or Insurance Case record page using the App Builder for Lightning Experience.
  2. Use Id in the Reference Field for Insurance Case Object
  3. Use InsuranceCase__c in Reference Field for Opportunity Object (or another objects with a 1:1 relationship to an Insurance Case).​
How To Test
  1. Start an iGO case associated with the parent record.
  2. Create a base coverage and a rider.
  3. Sync back to AgentOne (ensure that the rider is mapped on your org).
  4. Confirm that you see both Coverages in the component.

Enhancements

1. Introduce a lookup field to represent the agent user that owns the iGO case
​​​​​​Description:

With the introduction of Master Client Management (MCM), AgentOne now supports the ability for the iGO e-App owner to not be the same owner as the Insurance Case – Primary Insured’s owner. When MCM was introduced, we introduced a text field to store iGO owner, but it was not a lookup to a Salesforce system user which made it difficult to write reports. Some example report objectives that would benefit include “find me all Insurances Cases that I own.” Before AgentOne introduced Master Client Management (MCM), it was easy to derive the owner which is the Insurance Case – Primary Insured’s owner​.

​​​​​​Solution:

Create a new field called Primary Agent (Primary_Agent__c) which is a lookup to System User record that represents the Salesforce user owner of the iGO e-App. On manual creation of an Insurance Case through the UI, Primary_Agent__c field will be populated from the Insurance Case contact owner. Whenever there is sync record from the external system and an update happens on Insurance Case, AgentOne business logic will check for the igo_user value. If a valid user was found, this value will be populated. Otherwise, an exception is logged that a valid user could not be identified.

Risk Analysis: High

Affects which Fea​tures / Functionality:  IGO Integration

Availability: Automatic

​​

Implementation Steps

Optionally update MCM orgs to use this field on layouts and views.

Update Insurance Case Layout

  1. In Setup –> Object Manager, navigate to Insurance Case object.
  2. Edit Insurance Case layout (repeat for all).
  3. Add Primary Agent (Primary_Agent__c), and remove Agent (Agent_Owner__c) and (Owner Id) if it exists.

Update Insurance Case Views

  1. Navigate to Insurance Case views.
  2. Select an Insurance Case view with the field “Agent” listed in the view.
  3. Modify the fields.
  4. Edit fields an Insurance Case List Fields.
  5. Add Primary Agent (Primary_Agent__c), and remove Agent (Agent_Owner__c) and (Owner Id) if it exists.
How To Test
  1. Create an insurance case, confirm that Primary Agent is correctly populated.
  2. Trigger an insurance case sync, confirm that Primary Agent is correctly populated.
2. Get UpdatedBy User from iGO
​​​​Description:

AgentOne supports the On Behalf Of feature of iGO to allow authorized users to update the iGO e-App. Previously, AgentOne users were not able to audit who had edited the iGO e-App.Solution:

For every iGO sync back, the user who last updated the iGO case will now be synched back and stored to AgentOne for users to be able to view and report on. The new field is named iGO Case Last Updated By. Field tracking is enabled by default so that administrators can audit who has edited the iGO case.

​​​​​Risk Analysis: Low

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

Availability: Automatic

Implementation Steps

N/A

How To Test
  1. Log in as an agent that has sharing access to an Opp or Insurance Case owned by another agent.
  2. Launch iGO and update the iGO e-App.
  3. The iGO Case Last Updated By field on the Insurance Case should reflect the IGO user that last updated the iGO e-App.
3. Store RequestXML and ResponseXML only if Rerun Illustration Feature is enabled
​​​​​​Description:

RequestXML and ResponseXML were two files that were being created in AgentOne for every Illustration that was synched back to AgentOne. These files are only used for the Re-run illustration feature and are taking up file storage space in the org.

Solution:

Modified AgentOne to only retain these files when the Rerun Illustration feature is enabled in the Admin app.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Illustration Integration

Availability: Automatic

Implementation Steps

Ensure that the Rerun Illustration feature is disabled in the Admin app.

How To Test
  1. ​Launch iGO Illustrations.
  2. Run an illustration that syncs the Illustration back to AgentOne.
  3. Confirm that the Illustration record does not contain the RequestXML and ResponseXML files.

Fixes

1. In console, iGO intermittently created a new iGO case rather than opening the existing case
​​​​​​Description:

In Console, when there are multiple Opportunities or Insurance Cases open in different tabs, when selecting to start iGO, the iGO Lightning component intermittently results in unexpected behavior. It was sometimes creating a second iGO case or opening iGO on a different Opportunity record.

Solution:

The AgentOne Quick Start component is firing an Application event to open the iGO component. The Application event is listened by the whole application, so it was possible for any open Opportunity to listen and react to it. The console experience allows for multiple Opportunities to be opened at the same time, and this scenario wasn’t considered initially. The AgnetOne Quick Start component was initially designed for only one Opportunity record home page to be open at that time.​

When firing the event from the Quick Start component, we now pass the Salesforce record ID and tab ID. So any open Opportunities or Insurance Cases will first check if it matches to the same record and same tab. Only if it matches, it will open the iGO component. This fix applies to Insurance Case also.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Quick Start Component, iGO Integration, Opp Integration

Availability: Automatic

Implementation Steps

None

How To Test
  1. ​From the Lightning Console App, create a new Opportunity.
  2. Start a new iGO case.
  3. After iGO loads close the iGO component (screen will refresh and return to open Opportunity).
  4. Leave the Opportunity open and go to Opp home page.
  5. Create another new Opportunity.
  6. Start a new iGO case (leave the Quick Start component open for a few minutes).
  7. Click the ‘Start’ button to continue to load iGO.
2. Formula fields in the Insurance Case – Agent, Agent Number, Owner are not correct when MCM is on andor Opp Integration is on
​​​​​​Description:

The following three formula fields on the Insurance Case object are not correct when Master Client Management is enabled. These field values always stored the Agent as the Owner of the Primary Insured of the Insurance Case. They were created to be used in views or other logic that made it more convenient to have the value on the Insurance Case object.

  1. Agent Owner Name (Agent_Owner__c) – Name of Agent (from System User record)
  2. Agent Number (Agent_Number__c) – Agent Number of the Agent (from System User record)
  3. Owner Id (OwnerId__c) – textual GUID of the Agent which is a System User record
Solution:

The original sharing model of AgentOne was that the Agent is always the Owner of the Client record for the Primary Insured on the Insurance Case. These fields were created before the introduction of Master Client Management and Opportunity Integration support in AgentOne. When AgentOne first allowed support of public account sharing with Master Client Management (org-wide single shared client record identified by a master data management strategy) and Opportunity integration (agent owner to follow the opportunity owner), the formulas for these three fields were not adusted for differing case owner scenarios.

  1. Replaced Owner Id field with new Primary Agent lookup field on Insurance Case.
    Introduced a new lookup field called Primary Agent.  See Enhancement above, Introduce a lookup field to represent the agent user that owns the iGO case
    This field is intended to always be correct regardless of sharing model and it is a lookup field to the System User record. This field is meant to be synonymous with the Owner ID, but it is a lookup rather than plain text only.
    The Owner ID fields will be deprecated and has been relabeled to Deprecated – Owner Id in the July 2020 release. It will be deleted from the AgentOne managed package in a future release.
    Updated all Insurance Case Views, Report Types and Reports, Dashboards to replace old field with new Primary Agent lookup field wherever the old one was referenced.
  2. Renamed Agent Owner Name (Agent_Owner__c) to Agent Owner Name (System)
    It was determined that this field was being used in AgentOne business logic and therefore could not be deprecated.
    It has been renamed to Agent Owner Name (System)
  3. Renamed Agent Number (Agent_Owner__c) to Agent Number (System)
    It was determined that this field was being used in AgentOne business logic and therefore could not be deprecated.
    It has been renamed to Agent Number (System)

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Insurance Cases

Availability: Automatic

Implementation Steps

None

How To Test

See Enhancement above, Introduce a lookup field to represent the agent user that owns the iGO case

Sandbox Configuration Changes for Salesforce Summer ’20

New – Added July 21

Salesforce Summer 20 Release – Stabilize hostname for My Domain URLs in Sandboxes (Update, Enforced)
​​​​​​Description:

Salesforce enforced an update in the Summer ’20 release. It will be realized in sandbox orgs that were created prior to Summer ’18. Timing of the issue is that it is enforced starting when the parent Master org is updated (either Friday, July 10th or Friday, July 17th), depending on scheduled instance update.

Issue details from Summer ’20 Release Notes – Stabilize the Hostname for My Domain URLs in Sandb​​​​​​oxes (Update, Enforced)
When this update is enforced, instance names are removed from MyDomain URLS in sandbox. AgentOne has some configurations that rely on matching up to this URL in MyDomain. Therefore, if the domain changes, the AgentOne features will also be broken until the configurations are updated to match the new MyDomain URL.

Impacted Areas

These areas of AgentOne are potentially impacted

  1. Launching iGO
  2. iGO/ Pending Case Sync back is not working.
  3. Cannot load AgentOne Admin app
  4. Quick Start Component Loads with Errors
  5. AgentOne Home Page (Classic) Tiles

​​​​​Solution:

The resolution requires updating all references of domain names in AgentOne configuration to remove the instance from the URL.

Risk Analysis: Low

Affects which Fea​tures / Functionality: Quick Start Component, iGO Integration, Pending Case Feeds, Admin page

Availability: Required Manual Steps

Implementation Steps

Retrieve URL from My Domain

  1. In setup –> search My Domain
  2. Note the domain name for the org as this will be the domain name to matc in subsequent steps. (Instance has been removed).

Update Named Credentials

  1. In setup –> search App Manager
  2. Edit the connected App AgentOneApexApiApp
  3. Edit the CallBack URL to remove the instance . The domain name should match the URL in Retrieve URL from My Domain above.
    e.g.
    OLD: https://ao-fsc-manqa–manqa2.cs68.my.salesforce.com/services/authcallback/AgentOneApexApiAuth
    NEW: https://ao-fsc-manqa–manqa2.-cs68.-my.salesforce.com/services/authcallback/AgentOneApexApiAuth
  4. Wait 10 minutes.
  5. In setup –> search Named Credentials
  6. Click Edit _AgentOneApexApi. update the URL to remove the instance . The domain name should match the URL in Retrieve URL from My Domain​ above. Click save.
  7. Reauthenticate. (Note if you see an error, wait a little longer for Connected App change in step 4 to kick in which may take up to 10 minutes). Retry.
  8. Confirm the Quick Start component loads without error.

Update Admin App IDP setting

  1. Open AgentOne Admin app.
  2. Click on Global Settings.
  3. Edit the IDP to remove the instance . The domain name should match the URL in Retrieve URL from My Domain​ above. Click save.
  4. Confirm the AgentOne Home Page Tiles loads without error.

Update URL for iGO Single Sign On.

  1. Create a new certificate as you previously have for your org by going to Setup, and searching Certificate
  2. From Setup, search Identity Provider.
  3. Click on Edit, choose the new certificate and click save.
  4. Confirm that the issuer now match the URL in Retrieve URL from My Domain​ above.
  5. Click Download Metadata to get the metadata file.
  6. Send the metadata file to iPipeline following instructions below.
    Create a support ticket by sending this to iPipeline as follows:
    Subject: Please add AgentOne Org meta and Certificate
    To: tier3@ipipeline.com
    Subject: Add AgentOne SSO to iGO Certificate
    Attachment: metadata file
    Body: Please add the following certificate for AgentOne SSO to iGO
    Provide contact info – name, email, phone number.
    Specify the iGO environment you would like the metadata file registered with. Ie. QA, UAT, PROD
  7. From Setup, search Connected Apps.
  8. Click Edit next to the AgentOne SAML app that’s in use.
  9. In Issuer, edit to remove the instance. (I notice that leaving it blank also works)
  10. Once you hear back from support, test that the launching of iGO applications work successfully. It may take up to a day to work or may require you to shut down your browser, and clearing of the cache for it to work.

 Create New Remote Site

For this step, you can either create a new remote site or update the existing one to remove the instance name.

  1. If you would like to edit existing, find the remote site setting that matches your mydomain URL with the instance name.
  2. Edit the Remote Site URL to remove the instance .  The domain name should match the URL in Retrieve URL from My Domain​ above.
  3. Click save.

Update AgentOne Admin App URL

  1. From Setup, do a search for Apps (if you are in Classic) or search for App Manager in Lightning.
  2. Click on Apps under Create.
  3. Find and edit AgentOne Admin.
  4. Modify the Start URL to https://<domain>/AgentOne/AgentOneSettings.app. The domain name should match the URL in Retrieve URL from My Domain​ above.
  5. Click save.
  6. Load the AgentOne Admin app and confirm you can load it.

Update Data Integration Layer Mapping

Ask your professional services account manager to update the ESB mapping

How To Test

Confirm that impacted areas highlighted in the description above are operational again.

Enhancement and Fixes – enable ASAP (introduced with Feb 2020 release)

(Note the established date for final migrations set for the AgentOne August 2020 release dates)

1. 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 triggers.

The AgentOne January 2020 release included flow templates and process builder templates which were intended to provide the Pending Case Alerts logic on Salesforce.

In the February 2020 release, the business logic was removed from flow templates and process builder templates and moved into code. This is mainly due to the fact that it is not ideal to support all customer scenarios and be able to push out upgrades that will work for all customers. Therefore, the decision was to not use flow templates and process builder templates.

For the February 2020 release, the flow templates and process builder templates are intentionally left to be active but have been modified to exit and do nothing (empty). This is intended because we would like the February 2020 active version of the flows and process builders to replace the January 2020 active version. Eventually, the AgentOne package will deprecate the flow templates and process builder templates.

The following Flows are empty and now inactive (with March 2020):

  • ​DEPRECATED – AgentOne: Create requirement Received Alert​
  • DEPRECATED – AgentOne: Handle Pending Case Alerts

The following Process builders are active and empty:

  • DEPRECATED – AgentOne: Create Requirements Alerts
  • DEPRECATED ​ – AgentOne: ​​Insurance Case Record Create or Update
Salesforce doesn’t currently provide a method for partners to delete Flows and Processes Builders from AppExchange products.  As soon as that capability becomes available, we will delete these items.

Special deployment and QA notes for this enhancement and the relevant fixes that follow:

  • Packaged In February 2020 release – but not automatically enabled.
  • Flexibility is provided to so customers can enable it and schedule it into UAT testing when ready.
  • HIGHLY RECOMMENDED to enable this feature on UAT ASAP, if you had not already done so when it was introduced with the AgentOne February 2020 release or since, to maximize use of the remaining time to validate it.​​​​
  • Regression around Pending Case Feed testing is recommended if you have custom logic, post processing of Pending Case syncs.
  • Coordinate with PS Account Manager/Product Manager to enable feature.
  • This feature will eventually be enabled for any/all orgs that were not previously upgraded per the customer’s coordinated timeline, postponed from the original target of April 2020 to the AgentOne August 2020 release. ​​​​​ ​

Risk Analysis: Medium

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

Availability: Coordination (to enable) and testing steps, deadline to migrate TBD (as of March 16 2020)

Implementation Steps
  1. 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. (TBD)
    • disable Pending Case Alerts in the AgentOne data layer, at the same day and time
  2. Customers can choose to deactivate the Flows and Process Builder templates post February release.

Optional configuration: It is possible to customize the Policy Status Codes that generates the different Alert Types.

  1. From Setup, search ‘Custom Metadata Types’.
  2. Click Manage Records next to ‘Alert Type’.
  3. Click Edit next to the Alert Type that you would like to modify the codes for.
  4. Make your edits and click ‘Save’.
How To Test
  1. Sync in a Pending Case policy with an alert assigned to an agent or an alert that would generate a requirement received alert.
  2. Confirm that alerts creation and dismissal behavior ​are the same (other than associated fixed defects, below).
2. 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.
3. 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.​
4. Alerts for new requirements that accompany a case in a concluded or delivered status were dismissed immediately
​​​​​​Description:

Alerts for new requirements that accompany a case in CONCLUDED/DELIVERED status were dismissed immediately. AgentOne was dismissing all previous alerts, and was erroneously treating the new alert as a previous alert.

Solution:

Update for Policy 123 comes to AgentOne: Policy Number 123 comes in with Pending or Issued Status.

  • Open Req A
  • Open Req B

​Actual Behaviour: Alert for Requirements A and B is created.

Second Update for Policy 123: Policy Number 123 comes in with Pending or Issued Status.

  • Open Req A
  • Open Req B
  • Open Req C

​Actual Behavior: Alert A and B and C is created then dismissed.
​Expected Behavior: Only alerts for Requirement A and B should get dismissed.  Alert for Requirement C should be Active.

​​​​​Risk Analysis: Low

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

Availability: Enabled with Pending Case Alerts – move business logic to Salesforce

Implementation Steps

See Implementation Steps on Pending Case Alerts – move business logic to Salesforce

How To Test
  1. Test with an ACO​RD 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.​​
5. Requirement alert is not created when relationrolecode for the fulfiller party is 11 – agent 
​​​​​​Description:

Requirement alert was not created when RelationRoleCode for the fulfiller party type is a non-specific agent type role (tc=11 “agent”).

Solution:

New business logic was introduced in the data integration layer. If the pending case includes a requirement that has no Responsible Party Type but the specified fulfiller Party has the Relation Role type code of 11 (non-specific agent type), then it will set the Responsible Party Type to 1 (agent).

​​​​​Risk Analysis: Low

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

Availability: Enabled with Pending Case Alerts – move business logic to Salesforce

Implementation Steps

See Implementation Steps on Pending Case Alerts – move business logic to Salesforce

How To Test

1. Create an Accord file with the requirement that contains the following:

  • TXLife/TXLifeRequest/OLifE/Holding/Policy/RequirementInfo/ResponsiblePartyType is removed (or blank)
  • Holding/Policy/RequirementInfo/@FulfillerPartyID is for Agent Party with Relation/RelationRoleCode = 11
    e.g.:

2. Process the ACORD

 

Profile and Permission Set Changes

The​ following changes have been made to AgentOne permissions with the July 2020 release.

How to use this Info​​​​​
  • Since January 2019, iPipeline has highly recommended 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.  The release notes only reflect the changes since the immediate previous release.  Complete permission set permissions are documented in the AgentOne Implementation Guide.
  • 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
  • None
AgentOne Agent Permission Set
  • None
AgentOne Admin Permission Set
  • None
AgentOne System User Permission Set
  • None
AgentOne Support Permission Set
  • None
AgentOne Tabs Permission Set
  • None

 

July 2020 Deprecated and Deleted Items

AgentOne deletes metadata from the AgentOne Package in two phases, where the final/second phase is always in a subsequent release. This is to allow customers to plan for any changes in their orgs, if necessary.

How to use this Info​​​​​

Phase 1 – Deprecation​ iPipeline plans to delete it from the AgentOne package in a subsequent phase because it is no longer required or used by the AgentOne package.

  • The purpose of announcing that it will be deprecated is to allow customers the opportunity to do any planning, cleanup, or migration if they happen to be using the item.
  • The recommendation for items listed in this phase is to update any processes or perform any configurations needed to no longer used the deprecated item, if it is being used.

Phase 2 – Deletion​​ – iPipeline has deleted the item from the AgentOne package.  It is no longer referenced, but could exist on your org.

  • ​The purpose of announcing this phase is to let you know that the deleted item will still exist in your org, but you have the option to clean it up and delete it.
  • The recommendations at this phase include optional cleanup to delete the deprecated items from your orgs.  It typically is not a required step.
Deprecated Items
  • Insurance Case(InsuranceCase__c) object
    • ​​​Deprecated – Owner Id (AgentOne__OwnerId__c)
Deleted Items

None

 

 

Leave A Comment