AgentOne February 2020 Release Notes

Laura D'Anna AgentOne Release Notes

AgentOne February 2020 Release Notes

(updated Profile and Permission Set Changes – Feb 21 2020)

UAT Release: Feb 12, 2020 ~noon ET (completed)
Production Release: Feb 21, 2020  ~10:00pm ET

version 16.x

Go to top

Announcement

AgentOne Chrome 80 Update

(Deployed with iGO 9.2 Feb 1, 2020)

​​​​​​Description:

iGO fails to load from the AgentOne Canvas app or Lightning Component, or when attempting to e-Sign from an alert, when the Chrome settings (to simulate the default Chrome 80 increased security measures rolling out starting Feb 17) for ‘​​SameSite by default cookies’ and ​’Cookies without same site must be secure’ are enabled.
Solution:
Fixed to coincide with iGO January 2020 (9.2): Cookies that may be used in a 3rd party context are now being set with a SameSite attribute of “None”.
If the domain associated with a cookie matches an external service and not the website in the user’s address bar, this is considered a cross-site (or “third party”) context. The Chrome 80 release (scheduled for February 2020) changes the default cross-domain (SameSite) behavior of cookies from the default attribute of “Lax” to “None”. The change in the default attribute means that an iGO domain in the cookie, which doesn’t match the website in the address bar, can not be loaded. See the links below to the Salesforce KB article and Chrome blog for more details.

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: IGO Integration

Availability: Automatic

Implementation Steps

None

How iPipeline Tested

The following represents the progression of related product deployment events through at least February 17, when the Chrome 80 Same Settings begin rolling out for an initial limited population. iPipeline has validated all of these scenarios to ensure that iGO integration from AgentOne will be operational under all expected scenarios, and is well positioned to support the Chrome 80 launch without issue. Customer UAT validation is not required or expected, but iPipeline testing steps are provided should customers with to perform their own tests.

When​ Salesforce Release Google Chrome SameSite enabled iGO release
Today – Feb 1 Winter ’20 79 Off 9.1.x
Feb 1 – Feb 4 Winter ’20 79 Off 9.2
Starting Feb 4 Winter ’20 80 Off 9.2
Starting Feb 7 Spring ’20 80 Off 9.2
Starting Feb 7 Spring ’20 79, if not auto-updated Off 9.2​
​Starting Feb 17 ​Spring ’20 ​80 ​On ​9.2

​Enable SameSite – Simulate the Chrome 80 SameSite settings Feb 17+, using Chrome 79:

Note: To simulate the default Chrome 80 security settings, you will need to use a recent version of Chrome (e.g. 79.x), and to enable the SameSite settings below. These settings should only be tested against orgs running the Salesforce Spring ’20 release or prerelease (sandbox orgs with Spring ’20). If you have the Chrome 80 beta, these settings are already enabled by default.
  1. ​Open Chrome and go to the following page chrome://flags
  2. Search for ‘SameSite’
  3. ​Change the following settings to Enabled
    • SameSite by default cookies
    • Cookies without SameSite must be secure
  4. ​Restart Chrome

 

Launch iGO

  1. ​Open or create a client record
  2. Start a new case and proceed through the quick start component
    OR:
    Open an existing insurance case
  3. Start or open iGO

Sign from Alert (if enabled on your org)

  1. Create or open an insurance case
  2. Launch iGO and complete and lock the case
  3. Select ClickWrap (signature via email)
  4. Sign by all participants except the agent
  5. Confirm the signature required alert is synchronized and created in AgentOne
  6. Click the [Sign] action in Alert (either from the alerts Lightning Component, related list, or AgentOne home page)​

Disable SameSite – ​Simulate Chrome 79, or Chrome 80 state from Feb 4 through at least Feb 17

Note: If you have the Chrome 79 or previous, and have not enabled SameSite per the instructions above, these settings are already disabled by default. If the settings have already been enabled or you have Chrome 80 beta, disable them to test other scenarios. These settings must be disabled when testing with Salesforce Winter ’20.
  1. ​​Open Chrome and go to the following page chrome://flags
  2. Search for ‘SameSite’
  3. ​Change the following settings to Disabled
    • SameSite by default cookies
    • Cookies without SameSite must be secure
  4. ​Restart Chrome
  5. Repeat Launch iGO & Sign from Alert steps above
Important: If you are testing with the ‘SameSite’ settings enabled, then later disable the settings, you may be required to delete cookies before loading iGO. For example: If the user enables SameSite settings then launches SF Spring ’20 and starts a case If the user later disables SameSite settings and attempts to load iGO it could result in failure loading iGO. ​The solution is to delete cookies that were created while SameSite settings were enabled.

Enhancements

Flexible Filter for Case Requirements on the Requirements Lightning Component

​​​​​​Description:

Support a custom subset of requirements to be displayed in the AgentOne – Related Requirements lightning component, in addition to the previously supported options of (Not Received, All Requirements, or Received).

Solution:

AgentOne introduced an option in the existing ‘Requirements to Display’ fields called Other and a field below it labeled Filter for Requirements, which allows the administrator to select a view from the Case Requirements object.

​​​​​Risk Analysis: Low

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

Availability: Optional

Implementation Steps
  1. Create your requirements list view in the Case Requirements object
  2. Add the ‘AgentOne – Related Requirements’ component to a record home page
  3. Change the ‘Requirements to Display’ setting to Other
  4. Select the view created in step 1 in ‘Filter for Requirement’
Note: If you are already using this component with one of the original values in ‘Requirements to Display,’ you are not required to make any changes.  The component will continue to work as it had. If you open the Lightning App Builder for a record home page that already had the component previously added, you may notice that the ‘Filter for Requirements’ textbox is blank, and editing the component may show an error message. The error will not impact the display of the component, but if you select “None” in the Filter for Requirements, you can prevent the error from showing again.
How To Test
  1. ​Add the AgentOne – Related Requirements to your record home page (e.g. Insurance Case or Opportunity) as illustrated above
  2. Create or open an insurance case record that has some case requirements that match the filter in the Case Requirements view
Map Fulfilled Date from Case Requirement for Pending Case

​​​​​​Description:

Resonant identifies non-outstanding requirements with a completed date, that indicates if the Case Requirement has been either fulfilled or cancelled. A customer requested to be able to filter their Case Requirements by the Completed Date, rather than the Received Date, but this field was not yet mapped into AgentOne from the Pending Case Feed.

Solution:

AgentOne now supports a new field on Case Requirement for Completed Date (Fulfilleddate__c), and a new entry in the Entity Field List, to represent the date on which the requirement was fulfilled (for completed status) or cancelled (for cancelled status).  The new field is included on the Case Requirement layout.  The Resonant pending case feeds now include the new field, which is mapped to AgentOne via the data integration layer.  In addition, AgentOne now also allows admins and implementers to specify custom filters of requirements to display on the Requirements Lightning Component.  See feature Flexible Filter for Case Requirements on Requirements Lightning Component, above.

​​​​​Risk Analysis: Low

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

Availability: Automatic

Implementation Steps

None

How To Test
  1. Create an ACORD file for a Policy where there is a node for the TXLife\TXLifeRequest\OLife\Holding\Policy\RequirementInfo\FullfilledDate that has a valid date value.
  2. Send this ACORD to AgentOne.
  3. Confirm that the corresponding Insurance Case created or updated for this policy has the Completed Date matching the value in the ACORD.
Auditing and Logging for Transfer Scenarios

​​​​​​Description: Allow support users to troubleshoot issues related to Opp record ownership, iGO case ownership, and results of iGo case transfers.

Solution:

Introduced a Transfer Reason field on Insurance Case, plus logging for transfer that will identify 1) what triggered the transfer, 2) the transfer status, 3) results of the transfer [including previous and new iGO case owner], and 4) added history tracking on the fields (iGO User, Stransfer Status, and Transfer Reason).

​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: iGO Integration

Availability: Automatic

Implementation Steps

Optionally, you can also choose to enable field history tracking on the following fields on the Insurance Case object to track changes as a result of the iGO transfer.

  • ​iGO User (When transfer succeeds this will show the previous iGO case owner and the new owner.)
  • External User Id (When transfer fails this will show the previous iGO case owner and the new owner.)
  • Transfer Status (This will show the status of the transfer (either Success or N/A – when transfer failed).)
  • Transfer Status Text (This will show the previous and new value returned from the response from the transfer web service when the transfer failed.)
  • Transfer Reason (This will show the previous ane new value for what triggered the transfer.)
Steps (Lightning Experience):
1. While logged in as an administrative user go to Setup > Object Manager > Insurance Case
2. Go to Fields & Relationships and click on Set History Tracking
3. Enable the checkbox for each of the above mentioned fields
How To Test

Transfer from change in client ownership:

  1. Open an org that does not have Use.Master.Client.Management enabled
  2. Create or open a client record
  3. Start or open an iGO case (do not lock the case)
  4. Start or open another case for the same client (lock the case)
  5. Open the client record and change the owner
  6. Check the system job to confirm the transfer was performed (expectation is status will show Failed for the locked case)
  7. Go to Logs (AgentOne__Exceptions__c) and view logs (expectation is to see an entry logged for each case that was transferred)
    • log for open case should show success status and log the details of the transfer
    • log for the locked case should show failed status and details of the transfer

Transfer from change to opportunity ownership:

  1. Open an org that has opportunity integration enabled​
  2. Create or open a client record
  3. Open or create an opportunity
  4. Link an Insurance Case to the Opportunity and vice versa
  5. Change the owner of the opportunity
  6. Check the system job to confirm the transfer was performed (expectation is status will show Success assuming the case is not locked)
  7. Go to Logs (AgentOne__Exceptions__c) and view logs

Transfer triggered from pending case change in Primary Writing Agent:

  1. ​​​Open an org that has opportunity integration enabled​
  2. Create or open a client record
  3. Open or create an opportunity
  4. Link an Insurance Case to the Opportunity and vice versa​
  5. Take the case all the way to submitted status
  6. Process pending case sync record for the case where the primary writing agent changes
  7. Check the system job to confirm the transfer was performed (expectation is status will show Failed for the locked case)
  8. Go to Logs (AgentOne__Exceptions__c) and view logs (expectation is to see an entry logged for each case that was transferred)​
Update AgentOne Page Layouts to Use Files Instead of Notes and Attachment Related Lists

​​​​​​Description: AgentOne default page layouts still have Notes and Attachments in our related lists, when we have updated all of our code to use Files instead.

Solution:

Updated the following Page Layouts to replace Notes and Attachments in Related List with Files:

  • Account –> Account-AgentOne Business Account Layout.layout-meta.xml
  • Account-Individual Account.layout-meta.xml
  • ​Insurance Case Agent –> Agent__c-Agent Layout.layout-meta.xml
  • Illustration –> Illustration__c-Illustrations_Layout.layout-meta.xml
  • Policy Agent –>Inforce_Policy_Agent__c-Inforce Policy Agent Layout.layout-meta.xml
  • Insurance Case –>InsuranceCase__c-Insurance_Case In Phase Layout.layout-meta.xml
  • Insurance_Case Layout.layout-meta.xml
  • Policy Service Request –> Policy_Request__c-Policy Request Layout.layout-meta.xml
  • Trace –> Trace_Log__c-Trace Log Layout.layout-meta.xml
​​​​​Risk Analysis: Low

Affects which Fea​tures / Functionality: default AgentOne page layouts

Availability: Automatic for new installs; Optional Implementation Steps for existing orgs

Implementation Steps
  • Edit each Page layout listed
  • In the Related List section, remove Notes and Attachments
  • In the Related List section, add Files.
How To Test
  1. ​Install AgentOne into a new org, or follow Implementation Steps
  2. Confirm you see the above layouts with Files related list instead of Notes and Attachments.

Enhancement and Fixes – enable by April 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 active and empty:

  • ​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. (updated Feb 14 2020)

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 as soon as possible after Feb 12 on UAT, to allow for plenty of 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 is targeted to be enabled with the AgentOne April 2020 release dates for any/all orgs that were not previously upgraded per the customer’s coordinated timeline.​​​​​ ​
​​​​​Risk Analysis: Medium

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

Availability: Coordination (to enable) and testing steps, required before April 2020 production release

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. (i.e. March 2020 Prod release date)
    • 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).
Go to top
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

Implementation Steps

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

Implementation Steps

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 February 2020 release.

How to use this Info​​​​​
  • It is highly recommended that going forward that all AgentOne customers use permission sets to assign AgentOne permissions to their users.
  • All new implementations should rely on Permission sets as the primary means of assigning AgentOne permissions.
  • We continue to support orgs that do not currently use permission sets by documenting all the permission changes here in the release notes.
  • If you are not using the out of the box AgentOne Agent Permission set, then please reference the below changes to manually apply it to your cloned Permission Set or Profile as needed, following the respective AgentOne upgrade to the org.
​IMPORTANT: If your org is updated via Push Upgrade, then your Profiles will not get updated. Push upgrades do not give iPipeline the option to select Profiles to copy permissions to. If you are still relying on Profiles, then you will need to manually make Permissions changes to your Profiles. ​
AgentOne Agent Profile
    • Added permissions to the ‘RequirementCaseListView​’ Apex Class​​
      • Reason: Flexible Filter for Case Requirements on the Requirements Lightning Component
    • Added read permission to Case Requirement object –> Fulfilled Date (fulfilleddate__c)
      • Reason:  Map Requirements FulfilledDate field for AgentOne Pending Feed​
    • Added edit permission to Insurance Case –> Transfer Reason (Transfer_Reason__c)​
      • ​Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership
    • Added permissions to Alert_Code Custom Metadata
      • Reason:  Refactor Pending Case Alert – Migrate logic into Salesforce

(added with release note update Feb 14 2020)

    • Added read permission to Insurance Case –> Transfer Reason (Transfer_Reason__c)​
      • ​Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership
    • ​Added read permission to User –> iPipeline User (iPipeline_User__c)​
      • Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership

(added with release note update Feb 21 2020)

  • Added permissions to PendingCaseAlerts, RequirementCaseAlerts class
    • Reason:  Refactor Pending Case Alert – Migrate logic into Salesforce

(no longer needed – per release note update Feb 21 2020)

  • ​​Added permissions to DismissAlertsForPendingCase​, CreateReqirementAlerts, CreateAlertsForPendingCase, FeatureParameterForFlow​​ class
    • Reason:  Refactor Pending Case Alert – Migrate logic into Salesforce​
AgentOne Agent Permission Set
    • Added permissions to the ‘RequirementCaseListView​’ Apex Class​​
      • Reason: Flexible Filter for Case Requirements on the Requirements Lightning Component
    • Added read permission to Case Requirement object –> Fulfilled Date (fulfilleddate__c)
      • Reason:  Map Requirements FulfilledDate field for AgentOne Pending Feed​
    • Added edit permission to Insurance Case –> Transfer Reason (Transfer_Reason__c)​
      • ​Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership
    • Added permissions to Alert_Code Custom Metadata
      • Reason:  Refactor Pending Case Alert – Migrate logic into Salesforce
    • Added read permission to User –> iPipeline User (iPipeline_User__c)​
      • Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership​

(added with release note update Feb 14 2020)

    • Added read permission to Insurance Case –> Transfer Reason (Transfer_Reason__c)​
      • ​Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership
    • ​Added read permission to User –> iPipeline User (iPipeline_User__c)​
      • Reason:  Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership

(added with release note update Feb 21 2020)

  • Added permissions to PendingCaseAlerts, RequirementCaseAlerts class
    • Reason:  Refactor Pending Case Alert – Migrate logic into Salesforce

(no longer needed – per release note update Feb 21 2020)

  • ​​Added permissions to DismissAlertsForPendingCase​, CreateReqirementAlerts, CreateAlertsForPendingCase, FeatureParameterForFlow​​ class
    • Reason:  Refactor Pending Case Alert – Migrate logic into Salesforce​
AgentOne Admin Permission Set
  • Added edit permission to System Job –> Transfer Reason (Transfer_Reason__c)​
    • Reason: Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership​
AgentOne System User Permission Set
  • Added read permission to User –> iPipeline User (iPipeline_User__c)​​
    • Reason: Auditing and Logging for Transfer scenarios with Public OWD record ownership and iGO Case Ownership​
AgentOne Support Permission Set
  • None
AgentOne Tabs Permission Set
  • None

February 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, but if applicable, have been renamed to specify deprecated.

​Flows

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

Process Builders

  • 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.  (update Feb 14 2020)
Deleted Items

 

 

Tags:
Leave A Comment