AgentOne Release Notes

AgentOne March 2020 Release Notes

(updated March 30 – added one required manual step for Support for more granular delivery status events for all pending case feed orgs; March 20 – noted that Support for more granular delivery status events is available on UAT now;  March 16 – postponed deadline for pending alert migration until further notice, corrected auto-activation date for @auraenabled Salesforce critical update;  updated March 10 – see Availability section note on first item.)

UAT Release: Mar 11, 2020 ~noon ET
Production Release: Mar 20, 2020  ~10:00pm ET

version 17.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.

Enhancements

Pending Case Feeds – Support for more granular delivery status events

​​​​​​Description:

Resonant pending case feed case requirements represent unique original policy and delivery receipt requirement statuses from DocFast that were not fully available for agents to view in AgentOne.

Solution:

AgentOne now supports a new Case Requirements child custom object for Status Events.  Each Case Requirement may have one or more Status Event that is identified in the new business and underwriting system (Resonant).  As each status event occurs, it is time-stamped by Resonant and added to the list on the parent Case Requirement.  The Status Event related list can be displayed on the Case Requirement record home page, and the most relevant status event (most recently occurred) is added for immediate visibility in formula fields on Case Requirement, and on the Requirements Lightning component (available for Opp and Insurance Case).
Requirement Status Events (related list)
Latest Status Event Fields on Case Requirement

Latest Status Event, depicted on Requirement Lightning Component

 

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Pending Case Feeds , Lightning Components

Availability: Required Manual Step for all Pending Case Feed Orgs (updated March 30); additional Optional Steps for customers intending to leverage this enhancement

Note:  This feature is available on UAT as of Friday, March 20.  The availability for production orgs was deferred on March 27 and is TBD as of March 30, due to the identification of the REQUIRED MANUAL STEP noted below.
Implementation Steps
  • REQUIRED MANUAL STEP (Updated March 30):  Ensure that the pending case feed service account has all the AgentOne Admin Permission Set, or equivalent permissions, required to support this enhancement.  If you do not which account acts as the pending case service account, please consult with your AgentOne Professional Services representative.
    • ​Added Read/Write permissions to Requirement Status Event Object –> Status Event Code, Status Event Date/Time
    • ​Added ​Read/Write permissions to Case Requirement Object –> Latest Status Event,Latest Status Event Code, Latest Status Event Date/Time​​
    • Added Read/Write permissions to Sync Record Object –> Source Related Data​
  • Select the Sync Record entity to generate change event notifications
  1. While logged in as an administrative user go to Setup
  2. In the quick find box  type “Change Data Capture” and click on it
  3. From ‘Available Entries’ on the left select find ‘Sync Record (AgentOne__Sync_Record__c)’ and ​​move it to the ‘Selected Entries’ on the right
  • Modify Case Requirement Layout to add new fields.
  1. ​In Setup, go to Object Manager and search for Case Requirement.
  2. Click on Page Layouts and click on Case Requirements Layout.
  3. Add the following fields to the Layout: Latest Status Event, Latest Status Event Code, Latest Status Event Date/Time.
  • Add Related list onto Case Requirement Layout and configure.
  1. Next click on Related Lists add at top.
  2. Drag the related list Requirement Status Events on to the page.
  3. Configure the Related list and Select the following fields for the related list: Status Event, Status Event Code, Status Event Date/Time.
  4. Set the Sort By to Status Event Date/Time Descending.
  5. Disable the buttons (New and Change Owner).
  • ​Add new fields to Sync Record Layout.
  1. In Setup, go to Object Manager and search for Sync Record.
  2. Click on Page Layouts and click on Sync Record Layout.
  3. Add the following fields to the Layout: Source Related Data.
  • Add permissions for Requirement Status Event object to Profile or permission set.
    Because this object is in a master-detail relationship to a standard Salesforce object, permissions must be applied manually.  Please apply it to the permission set or profile the same way you applied permissions for the AgentOne Insurance Case or Case Requirement object.
How To Test
  1. Sync to AgentOne an 1125 Pending Case feed that contains the TXLife/TXLifeRequest/OLifE/Holding/Policy/RequirementInfo/StatusEvent node.
  2. Confirm that the Status Events are created in AgentOne for the corresponding Insurance Case under the Case Requirement it is associated to.
  3. If applicable, view the Insurance Case or related Opp on a record home page with the Requirements Lightning Component, and confirm the status event description and date stamp are displayed at the bottom of the parent Case Requirement.
Retain flat extras and other related extra premium fields from iPipeline Illustrations

​​​​​​Description:

As an insurance carrier, I want my agents to be able to track additional flat premiums (flat extras) and percentage premiums (table ratings) in AgentOne so they can service their clients better.

Solution:

Introduce new fields on the Illustration and Insurance Case objects for the following:

  • Table Rating (note this field already exists on insurance case)
  • Temp Flat Extra Amount
  • Perm Flat Extra Amount
  • Temp Flat Extra Duration

Sync values for the above mentioned fields from iGO when an Illustration is generated, and update to Illustration record and parent Insurance Case record.

When the case is submitted the current values on the above mentioned “flat extra” fields are copied to their “Applied for…” equivalent fields on the Insurance Case.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Illustrations Integration

Availability: Optional

Implementation Steps

The iPipeline implementation team needs to provide iGO VocabMapper mappings for data dictionary fields:

  • POL_TEMPLFLATEXTRADURATION –> iGO project field name
  • POL_TEMPFLATEXTRAAMT –> iGO project field name
  • POL_PERMFLATEXTRAAMT –> iGO project field name
  • POL_PERMTABLERATING_TC –> HOOK (translate iGO values to ACORD)
  • PI_POL_LP_PERMTABLERATING_TC –> HOOK (translate iGO values to ACORD)
  • POL_POLICYSTATUS_TC –> iGO project field name

Manual post deployment steps page layouts:

    1. Update the insurance case page layout (Insurance_Case In Phase Layout)​
      • ​Add the ‘Flat Extra’ section and the regular and applied for flat extra fields
    2. Update the illustration page layout (Illustrations_Layout)​​
      • ​Add the ‘Flat Extra’ section and the flat extra fields
How To Test
  1. Configure AgentOne with Illustration integration (related Illustrations project must have the ability to add flat extra fields to the illustration)
  2. Start iGO for a new case
  3. Select State, Product Type, and Product
  4. Go to Illustrations tab
  5. If the Illustrations project has a Pre-Qualify option, populate all required fields
  6. Change ‘Rate Class’ to “Preferred” or “Standard”
  7. If the Illustration project has a Rating button, click it and select a Table Rating, select a Flat Extra Type (e.g. Temporary), enter Flat Extra Amount, and (if temporary) enter a duration for Years
  8.  Run an Illustration
  9. Wait for sync back of illustration completed event then open the illustration record and confirm flat extra fields are populated
  10. Open the parent Insurance Case record and confirm current flat extra fields are populated on the parent case
  11. Submit the case and confirm the applied for flat extra fields are populated on the insurance case
Salesforce Critical Update Support – Restrict Access to @AuraEnabled Apex Methods for Authenticated users Based on User Profile

​​​​​​Description:

Salesforce is enforcing a Critical Update that will be auto-enabled in all orgs soon.  The Salesforce release note, and instructions to identify the auto-activation date (June 5 as of March 16 2020), can be found here.

Solution:

Grant AgentOne Aura and Lightning Web Components to AgentOne permissions.
  • Added to Agentone Agent permission set and Profile – AlertList_Controller, AuraService, CaseButtonComponentController, iGOApp_Controller, InsuranceCaseRelatedList_Controller, InsuranceToolDataAccess, QuickCaseStartController
  • Added to Agentone Support perm set – SyncSearchPage_Controller
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality:  Salesforce Security Support

Availability: Automatic

Implementation Steps

None

How To Test
  1. Activate the Salesforce Critical Update – Restrict Access to @AuraEnabled Apex Methods for Authenticated Users Based on User Profile​​.
  2. Load a home page or record home page that contains AgentOne Lightning components.
  3. Confirm that you are able to see the component(s) with no errors.

Fixes

Pending Case Sync records where agent is not equal to the client owner changes the client owner, with Master Client Management and Opp Integration

​​​​​​Description:

In an environment that is setup with custom client matching logic, when the pending case feed is received and processed and if the primary writing agent on the case is not the current owner of the client record, AgentOne would incorrectly change the client owner to the user associated to the primary writing agent on the pending case.
The business logic was not handling the scenarios when 1) custom matching logic for Account is used, and 2) the org is setup with Opportunity Integration enabled, and/or 3) Use Master Client Management is enabled.

Solution:

Updated the AgentOne product pending case business logic to handle the combination of configuration scenarios that was not previously addressed.
​​​​​Risk Analysis: High

Affects which Fea​tures / Functionality: Pending Case Feeds

Availability: Automatic

Implementation Steps

None

How To Test
  1. Setup the org to use a custom matching logic (or change to use the tax ID matching logic instead of the default matching logic)
  2. Ensure the org has Opportunity Integration enabled and/or Use Master Client Management enabled
  3. Create an account owned by Use A, and Opportunity owned by User B
  4. Start iGO for the opportunity owned by User B and take the case all the way to submitted status
  5. Process a pending case sync record for the case from step 4 and make sure the primary writing agent is User B
  6. After the pending case sync record is processed confirm that the account remains owned by User A
Inbound sync for Illustration completed event does not update Contact data

​​​​​​Description:

For each illustration that is run and saved to AgentOne (ILLUSTRATION_COMPLETED events), we want to update the Primary Insured client details in AgentOne.  The sync record for an ILLUSTRATION_COMPLETED only created a new illustration record and saved the PDF against the illustration.  It was not orignally designed to update the client record, as well.

Solution:

Create a DATA_CHANGE event for every ILLUSTRATION_COMPLETED event received and processed.
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Illustrations Integration

Availability: Automatic

Implementation Steps

None

How To Test
  1. ​​​Start or open an iGO case for an existing client
  2. In iGO/Illustrations platform, change some client info (e.g. First Name, Last Name, Birthdate, etc…)
  3. Run an illustration and wait for sync back to AgentOne
  4. Check the client record to confirm that the modifications from step 2 are made​
  5. If you’re interested in seeing the behind-the-scenes sync records, check the sync records and confirm that two entries were created (for DATA_CHANGE and ILLUSTRATION_COMPLETED events)
Inbound sync for Illustration does not update Insurance Case once Application tab has been visited

​​​​​​Description:

We would like the event received when running an Illustration (ILLUSTRATION_COMPLETED events) to update the parent insurance case in AgentOne even after the phase moves from Illustration to Application.  The sync record for an ILLUSTRATION_COMPLETED only created or updated the parent Insurance Case record while the case was in the Illustration phase.  Once it moved to Application phase, future illustrations were not previously designed to update the parent Insurance Case record.

Solution:

Create a DATA_CHANGE event for every ILLUSTRATION_COMPLETED event received and processed.
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Illustrations Integration

Availability: Automatic

Implementation Steps

None

How To Test
  1. Start or open and iGO case for an existing client
  2. In iGO / Illustrations, after running an illustration switch to the Application tab and confirm the sync back to AgentOne changes the phase to “Application”
  3. In iGO / Illustrations, change some details on the case (e.g. Coverage Amount, Product, etc…)
  4. Run another illustration and wait for sync back to AgentOne
  5. Check the parent insurance case record to confirm that the modifications from step 3 are made
  6. If you are interested in seeing the behind-the-scenes sync records that drive this enhancement, check sync record and confirm that two entries are created (for DATA_CHANGE and ILLUSTRATION_COMPLETED events)​
Inbound sync for Illustration does not update Product Code on Insurance Case

​​​​​​Description:

If the Illustrations screen in iGO allows changing the product. we would like the event received when running an Illustration (ILLUSTRATION_COMPLETED events) to update the Product Code on the parent Insurance Case in AgentOne.  The sync record for an ILLUSTRATION_COMPLETED only updated the product on the illustration record, but did not update the parent Insurance Case.

Solution:

Create a DATA_CHANGE event for every ILLUSTRATION_COMPLETED event received and processed.
​​​​​Risk Analysis: Medium

Affects which Fea​tures / Functionality: Illustrations Integration

Availability: Automatic

Implementation Steps

None

How To Test
  1. ​​​Start iGO case for an existing client
  2. In iGO / Illustrations, select a product and run an illustration and confirm the sync back to AgentOne sets the product on the illustration and insurance case
  3. In iGO / Illustrations, change the product from the Illustration tab and run another illustration then wait for sync back to AgentOne
  4. Check the parent insurance case record to confirm that the product code is updated to reflect the product selected from step 3
  5. If you are interested in seeing the behind-the-scenes sync records that drive this fix, check the sync records and confirm that two entries are created (for DATA_CHANGE and ILLUSTRATION_COMPLETED events)

Enhancement and Fixes – enable ASAP (introduced with Feb 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 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 March 11, if you have not already done so when it was introduced with the AgentOne February 2020 release, 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, with a deadline to be identified and announced to be determined, postponed from the original target of April 2020 on March 16 2020.​​​​​ ​
​​​​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).
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.​

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.​​

 

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 March 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
    • ​​​Reason: SF Critical Update Support – Restrict Access to @AuraEnabled Apex Methods for Authenticated Users Based on User Profile
      • Added permissions to the following classes: AlertList_Controller, AuraService, CaseButtonComponentController, iGOApp_Controller, InsuranceCaseRelatedList_Controller, InsuranceToolDataAccess, QuickCaseStartController
    • Reason: Pending Case Feeds – Support for more granular delivery status events
      • ​Added Read permissions to Requirement Status Event Object –> Status Event Code, Status Event Date/Time
      • ​Added ​Read permissions to Case Requirement Object –> Latest Status Event, Latest Status Event Code, Latest Status Event Date/Time​
    • Reason: Retain flat extras and other related extra premium fields from iPipeline Illustrations
      • Added Read permissions to the Insurance Case object –> Applied for Temp Flat Extra Duration, Applied for Perm Flat Extra Amount, Applied for Temp Flat Extra Amount, Temp Flat Extra Duration, Perm Flat Extra Amount, Temp Flat Extra Amount
      • Added Read/Write permissions to Illustration object –> Temp Flat Extra Duration, Perm Flat Extra Amount, Temp Flat Extra Amount, Table Rating
AgentOne Agent Permission Set
    • ​​​Reason: SF Critical Update Support – Restrict Access to @AuraEnabled Apex Methods for Authenticated Users Based on User Profile
      • ​​​​​Added permissions to the following classes: AlertList_Controller, AuraService, CaseButtonComponentController, iGOApp_Controller, InsuranceCaseRelatedList_Controller, InsuranceToolDataAccess, QuickCaseStartController
    • Reason: Pending Case Feeds – Support for more granular delivery status events
      • ​Added Read permissions to Requirement Status Event Object –> Status Event Code, Status Event Date/Time
      • ​Added ​Read permissions to Case Requirement Object –> Latest Status Event,Latest Status Event Code, Latest Status Event Date/Time​
    • Reason: Retain flat extras and other related extra premium fields from iPipeline Illustrations
      • Added Read permissions to the Insurance Case object –> Applied for Temp Flat Extra Duration, Applied for Perm Flat Extra Amount, Applied for Temp Flat Extra Amount, Temp Flat Extra Duration, Perm Flat Extra Amount, Temp Flat Extra Amount
      • Added Read/Write permissions to Illustration object –> Temp Flat Extra Duration, Perm Flat Extra Amount, Temp Flat Extra Amount, Table Rating
AgentOne Admin Permission Set
  • ​​​Reason: SF Critical Update Support – Restrict Access to @AuraEnabled Apex Methods for Authenticated Users Based on User Profile
    • Added permissions to the following classes: SyncSearchPage_Controller
  • Reason: Pending Case Feeds – Support for more granular delivery status events
    • ​Added Read/Write permissions to Requirement Status Event Object –> Status Event Code, Status Event Date/Time
    • ​Added ​Read/Write permissions to Case Requirement Object –> Latest Status Event,Latest Status Event Code, Latest Status Event Date/Time​​
    • Added Read/Write permissions to Sync Record Object –> Source Related Data​
  • Reason: Retain flat extras and other related extra premium fields from iPipeline Illustrations
    • Added Read/Write permissions to the Insurance Case object –> Applied for Flat Extra Duration, Applied for Permanent Flat Extra Amount, Applied for Temporary Flat Extra Amount, Flat Extra Duration, Permanent Flat Extra Amount, Temporary Flat Extra Amount
    • Added Read/Write permissions to Illustration object –> Flat Extra Duration, Permanent Flat Extra Amount, Temporary Flat Extra Amount, Table Rating
AgentOne System User Permission Set
  • None
AgentOne Support Permission Set
  • None
AgentOne Tabs Permission Set
  • None

March 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

The items in this list still exist in the AgentOne package.  The difference in March 2020 release vs Feb 2020 release is that that they are now changed to Inactive.

Flows

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

Process Builders

  • DEPRECATED – AgentOne: Create Requirements Alerts – changed to inactive
  • DEPRECATED – AgentOne: ​​​​Insurance Case Record Create or Update ​- changed to inactive
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.
Deleted Items

 

 

Leave A Comment