AgentOne Release Notes

AgentOne June 2020 Release Notes

UAT Release: June 10, 2020 ~noon ET
Production Release: June 19, 2020  ~10:00pm ET

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

Ensure there is an Opportunity for every Insurance Case (no orphaned Insurance Cases)

​​​​​​Description:

As an agent using an Opportunity workflow provided by the object with Financial Services Cloud, Sales or Service Cloud or similar from Salesforce that provides its license, I want to associated the Insurance case with exactly one Opportunity so that there are no orphaned insurance cases.  If the associated Opportunity cannot be identified by an existing Opportunity, I want to automatically create a new one.

Solution:

  1. Flow Template – Find Matching Opportunity for Insurance Case
  2. Created a Report – Opportunity Matching in AgentOne folder​
  3. Create a Report Type – AgentOne Logs to allow report creations on Log (AgentOne__Exception__c) object.
    • Report on Opportunity matching attempts so only Log records with event id = 9211,9212, or 8210
  4. Create a new view on Log object – Opportunity Matching
    • view showing Opportunity matching attempts so only Log records with event id = 9211,9212, or 8210
  5. Modified the Create Logs for Flows ​to pass it more parameters to create a log record.
More details for Solution step 1:  Flow Template – Find Matching Opportunity for Insurance Case
The flow template is intended for customers to clone and make changes according to their organization’s business logic.  The flow template has logic to do the following:
  • find matching opportunities​
  • create a new opportunity if no match found.
  • link it to an existing opportunity if one was found.
  • create log messages for each time this flow runs, providing links to insurance cases and created and linked opportunities (useful for reporting) with the following values:​

Subject: Opportunity Matching – Multiple matches found
Level WARN
Event ID 9211
Object Name: Insurance Case
Exception Message:  ​
Multiple Opportunities were found for Insurance Case – [Insurance Case Name here] (URL)
– Opp for John Doe 1 (opp url)
– Opp for John Doe 2 (opp url)

Subject: Opportunity Matching – No match found, new Opportunity created
Level: INFO
Event ID 9212
Object Name: Insurance Case
Exception Message:  ​
​Opportunity  – [Opp Name here] (URL) was created for Insurance Case – Case for John Doe

Subject: Opportunity Matching – Match Found
Level INFO
Event ID 8210
Object Name: Insurance Case
Exception Message:  ​
Opportunity – [Opp Name here] (URL) was matched and linked to Insurance Case – [Insurance Case Name here]

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Opportunity Integration

Availability: Optional, enabled by iPipeline

Implementation Steps
Pre-requisites:
  1. Clone the flow template Find Matching Opportunity for Insurance Case​.
  2. Modify the flow to match your organization’s business logic.
    • Review the search criteria for finding opportunities.
    • Review the creation of the new opportunity if one is not found.
  3. Once you are happy with your flow, save and activate.
  4. Create a process builder that will call this flow upon creation of an Insurance Case.
How To Test

TBD

Enhancements

Receive Illustrations PDF as Salesforce Files instead of Notes and Attachments

​​​​​​Description:

Salesforce Files now replace the older standard objects for Notes and Attachments.  AgentOne had migrated to use Salesforce Files on the Illustrations object but data integration layer is still sending the PDF as a Notes and Attachment on the Sync record.  There is no functionality difference for the end user.  The processing is on the sync record and should behave the same for the user.

Solution:

Updated AgentOne code to receive the PDF as a Salesforce File on the Sync record, and updated the data integration layer to send PDF as Salesforce Files.
If the sync record exit code is greater than or equal to 1, illustration file will be linked to Illustration record.
​If the sync record exit code is less than 1 , the PDF won’t be linked to the Illustration, and documents will not be created for request and response xml.
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: Illustrations Integration

Availability: Automatic

Implementation Steps

None

How To Test

1. Launch iGO and save an Illustration.

2. Open the corresponding newly created Illustration record in AgentOne.

3. Confirm that the PDF is correctly saved to the record.

Include Logging for Transfer to include DTC details

​​​​​​Description:

Direct-to-consumer cases are difficult to triage.  During a Transfer, there was no indication if it was for a DTC case.
In order for administrative or support users to troubleshoot transfer issues more effectively, they would like to see details of the direct-to-consumer (DTC) case on the logged entry for every transfer, so they can identify if the case was previously owned by a specific iGO DTC anonymous user.   The log entry should clearly state if the transferred case was a DTC case, so they don’t need to manually analyze the previous and new user names.

Solution:

Whenever there is a transfer from the client, pending case, or opportunity we are logging two additional fields and values on the log object record as shown below:
  • Original Mode of Application: DTC (Direct to Consumer)
  • ​iGO Case Owned by Randomly Generated User: FALSE (previous value was true)

​​​​​Risk Analysis: Low

Affects which Features / Functionality: Error Handling

Availability: Automatic

Implementation Steps

None

How To Confirm

1. Transfer a DTC case

2. Confirm that you see a log and that it’s correctly showing the original mode of application as DTC and the iGO Case Owned by Randomly Generated User as FALSE.

Support prefill for any party type and related contacts to iGO – e.g. secondary addressee

​​​​​​Description:

Extend the supported prefill integration for insurance case participants between AgentOne and iGO to include other participant types (e.g. Secondary Addresee).

Solution:

Changed the code for prefill from insurance case party to iGO making the previously hard coded party type records dynamic. This is configurable via a custom metadata type setting that allows mapping the iGO prefix “Code” for a given party type.
The “Party Type” specified in the Custom Metadata Types setting shown above must match the ‘API Name’ of the values in the picklist for the field ‘Type (AgentOne__Type__c)’ on the Insurance Case Participants (Insurance_Party) object.

Risk Analysis: Medium

Affects which Features / Functionality: iGO Integration

Availability: Optional

Implementation Steps
In Setup –> Object Manager
  • Navigate to Insurance_Party_c object
  • Click on (Type) Type_c field 
  • Add Secondary Addressee picklist value
The default prefill setting for party already exist but are required to be mapped to the associated iGO TO FIELD NAME in Vocab Mapper.
Default Prefill Settings:
​NAME​ FROM ENTITY NAME​ ​SELECT FIELDS FROM ​FROM FIELD NAME TO FIELD NAME​
​CD_PARTY_FirstName ​parties ​name (first name) ​{t}_FirstName__{p}
​CD_PARTY_FullName ​parties ​name ​{t}_FullName__{p}
​CD_PARTY_InterestPercent ​parties ​Allocation__c ​{t}_InterestPercent__{p}
​CD_PARTY_LastName ​parties ​name (last name) ​{t}_LastName__{p}
​CD_PARTY_Mailing_City ​parties ​contact ​mailingcity ​{t}_ADDR_Bus_City__{p}
​CD_PARTY_Mailing_Country ​parties ​contact ​mailingcountry ​{t}_ADDR_Bus_AddressCountryTC_tc__{p}
​​CD_PARTY_Mailing_State ​parties ​contact ​mailingstate ​{t}_ADDR_Bus_AddressStateTC_tc__{p}
​CD_PARTY_Mailing_Street ​parties ​contact ​mailingstreet ​{t}_ADDR_Bus_Line1__{p}
​CD_PARTY_Mailing_Zip ​parties ​contact ​mailingpostalcode ​{t}_ADDR_Bus_Zip__{p}
​​CD_PARTY_RelationDescription_tc ​parties ​Relationship_to_Primary_Insured__c ​{t}_RelationDescription_tc__{p}
How To Test

Pre-requisite: Work with your Professional Services Account Manager to perform the required implementation steps for the carrier’s Vocab Mapper project.

Steps:

  1. Create a new insurance case for a given client in AgentOne (but do not start iGO)
  2. Open the saved insurance case and go to Insurance Case Participants related list
  3. Add at least one party record and select the party type (e.g. Secondary Addressee)
  4. Select an existing client record on the party record created in step 3
  5. Start iGO for the given case
Support sync for secondary addressee and contact from iGO

​​​​​​Description:

Extend the supported integration with iGO for synchronization of insurance case participants to include other participant types (e.g. Secondary Addressee) and include configuration settings allowing an administrative user to determine whether a client record should be created/updated.

Solution:

Changed the code for sync to insurance case party from iGO making the previously hard coded party type records dynamic. This is configurable via a custom metadata type setting that allows mapping the iGO prefix “Code” for a given party type.
The “Party Type” specified in the Custom Metadata Types setting shown above must match the ‘API Name’ of the values in the picklist for the field ‘Type (AgentOne__Type__c)‘ on the Insurance Case Participants (Insurance_Party) object.
Application Configuration
(the following application configuration settings has been introduced for ‘Secondary Addressee’ allowing selection of record type and enabling the creation or update of the client record)
Name ​Value ​Category
​Secondary Addressee Record Type ​PersonAccount ​RecordType
​Application Secondary Addressee 0 – Do not create or update client ​Client Record
NOTE: The default is set to NOT create/update the client record when a secondary addressee participant record is created (see ‘Application Secondary Addressee’ setting above). If this setting is changed to “1 – Create or update person account” then the default record type of “PersonAccount” will be used.
Sync Mapper​
The following existing sync mapper settings are modified for synchronization of the secondary addressee.  Bold font identifies the change to existing sync mapper settings.
Label Entity Name​ ​Input Fields ​Output Field ​Transform Action
​iGO.App.PAx.Fld.name ​InsuranceAppEntry
$.{t:OWNP|PB|PYR|CB|JOWN}_FULLNAME__{x:1-}
$.{t:OWNP|PB|PYR|CB|JOWN}_FIRSTNAME__{x:1-}
$.{t:OWNP|PB|PYR|CB|JOWN}_MIDDLENAME__{x:1-}
$.{t:OWNP|PB|PYR|CB|JOWN}_LASTNAME__{x:1-}
​$.parties[{t+x}].fieldMap.name.value ​ToFullName($.{t}_FULLNAME__{x}, $.{t}_FIRSTNAME__{x}, $.{t}_MIDDLENAME__{x}, $.{t}_LASTNAME__{x})
​iGO.App.PAx.Fld.type__c ​InsuranceAppEntry ​$.{t:OWNP|PB|PYR|CB|JOWN}_LASTNAME__{x:1-}

$.{t:OWNP|PB|PYR|CB|JOWN}_FULLNAME__{x:1-}
​$.parties[{t+x}].fieldMap.{ns}type__c.value ​IF(t==”OWNP”, “Owner”, IF(t==”PB”, “Primary Beneficiary”, IF(t==”PYR”, “Payor”, IF(t==”CB”, “Contingent Beneficiary”, IF(t==”JOWN”, “Secondary Addressee”)))))
​iGO.App.PAx.objectType ​InsuranceAppEntry ​$.{t:OWNP|PB|PYR|CB|JOWN}_LASTNAME__{x:1-} ​$.parties[{t+x}].objectType ​”insurance_party__c”​

More than 25 new sync mapper settings are introduced for the synchronization of the seconandary addressee.  You can find these settings by searching for the standard label prefix of iGO.App.PAx.RE.CON.SEC​ in the Sync Mapper in the AgentOne Admin App.   Please contact the AgentOne product mangaer or your professional services account manager if you would like the detailed list from the iPipeline internal release notes.

Risk Analysis: High

Affects which Features / Functionality: iGO Integration, Sync Mapper – AgentOne Admin App, Sync back of all insurance case participants existing existing including owners, payors, beneficiaries, etc.

Availability: Optional

Implementation Steps
The default sync settings for party will be installed as part of this feature but are required to be mapped to the associated iGO field name by your AgentOne Professional Services Project Team.
How To Test

Pre-requisites:

  • Perform the required implementation steps for the carrier’s Vocab Mapper project.
  • Update the Application Configuration settings identified above to create/update the client record

Steps:

  1. Create a new insurance case for a given client in AgentOne (start iGO)
  2. Answer the question asking if there is a secondary addressee
  3. Add details for the Secondary Addressee (making sure minimum required fields for contact matching logic are entered. e.g. First Name, Last Name, Phone)
  4. Trigger a sync back to AgentOne
  5. Open the Insurance Case in AgentOne and go to Insurance Case Participants related list to confirm the Secondary Addressee party record and related client were created
Support date transformation in Sync Mapper

​​​​​​Description:

Introduce the ability to accept date values from iGO and transform the date to the expected Salesforce date format without having to rely on hooks in the iPipeline mapping layer.

Solution:

Added the CONVERTDATE function to transform action from sync mapper settings for specified date formats to standard Salesforce formats.
The CONVERTDATE function supports the following date formats:
  • mm/dd/yyyy
  • yyyy-mm-dd
  • yyyy-mm-dd hh:mm:ss
Supported ​Functions Example​ of Transform Action on Sync Mapper Setting ​Example of Dates Accepted in Sync Record
​mm/dd/yyyy ​CONVERTDATE($.PI_BIRTHDATE__{x},”MM/DD/YYYY”) “​12/31/2020”
​yyyy-mm-dd ​CONVERTDATE($.PI_BIRTHDATE__{x},”YYYY-MM-DD”) “​2020-12-31” OR “2020-12-31 T00:00:00 +00:00”
​yyyy-mm-dd hh:mm:ss ​​CONVERTDATE($.PI_BIRTHDATE__{x},”YYYY-MM-DD HH:MM:SS”)​ ​”2020-12-31 00:00:00″

Risk Analysis: Medium

Affects which Features / Functionality: iGO Integration, AgentOne Admin App – Sync Mapper

Availability: Automatic

Implementation Steps
None
How To Test

1. Create a new sync mapper setting that maps from an iGO date field to a SF date field

2. Make sure that the sync mapper setting includes the CONVERTDATE function in Transform Action

e.g. CONVERTDATE($.PI_BIRTHDATE__{x},”MM/DD/YYYY”)

3. Process a sync record that sends the date field from iGO using the mm/dd/yyyy format

e.g. “PI_BIRTHDATE”: “12/31/1980”

4. Confirm the sync record processes succesfully and the date is correctly represented in Salesforce (regardless what date format/localization is used by the Salesforce user)

 

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)

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).
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 June 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
    • Missing Permissions were identified for Insurance Case
      • Added ​Read permissions to following Insurance Case Object fields
        • ​Annualized Premium (Annualized_Premium__c)
        • External User Id (External_User_Id__c)
        • Last Sync Error Msg (Last_Sync_Error_Msg__c)
        • Last Sync Exit Code ​(Last_Sync_Exit_Code__c)
        • Last Sync Message Tracking Id​(Last_Sync_Tracking_Id__c)
        • (Last_Sync_Request__c​)
        • (Last_Sync_Source__c​)
        • (Sync_Fields_Last_Updated__c)
        • (Sync_Record__c)
        • (Sync_Record_Id__c)
      • Added permissions to the following classes
        • ​UIListController
        • UILookupController
AgentOne Agent Permission Set
    • Missing Permissions were identified for Insurance Case
      • Added ​Read permissions to following Insurance Case Object fields
        • ​Annualized Premium (Annualized_Premium__c)
        • External User Id (External_User_Id__c)
        • Last Sync Error Msg (Last_Sync_Error_Msg__c)
        • Last Sync Exit Code ​(Last_Sync_Exit_Code__c)
        • Last Sync Message Tracking Id​(Last_Sync_Tracking_Id__c)
        • (Last_Sync_Request__c​)
        • (Last_Sync_Source__c​)
        • (Sync_Fields_Last_Updated__c)
        • (Sync_Record__c)
        • (Sync_Record_Id__c)
AgentOne Admin Permission Set
  • Missing Permissions were identified for Insurance Case
    • ​Added ​Edit permissions to following Insurance Case Object fields
      • ​Annualized Premium (Annualized_Premium__c​)
      • External User Id (External_User_Id__c​)​
      • iGO Case Owned by Random User (iGO_Case_Owned_by_Random_User__c)
      • Transfer Reason (Transfer_Reason__c​)
    • Added ​Edit permissions to following Insurance Case Requirement fields
      • Completed Date (FulfilledDate__c)
      • ​Has Chat Messages? (Has_Chat_Messages__c)
AgentOne System User Permission Set
  • None
AgentOne Support Permission Set
  • None
AgentOne Tabs Permission Set
  • None

June 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

None

Deleted Items

None

 

 

Leave A Comment