Duplicate SLAs attach in New York and Orlando when SLA Definitions are stored on OOB contract_sla table AND custom table containing name "contract_sla"DescriptionThe user had SLA Definition "Apple" stored in the Out of Box (OOB) SLA Definition table contract_sla. The user also had the same SLA Definition "Orange" stored in their custom SLA Definition table u_contract_sla_config. In New York and Orlando family releases, this was causing "duplicate" task SLAs to attach to task records (in actuality, the system was just attaching the matching SLA Definition "Apple" from the OOB contract_sla table and the SLA Definition "Orange" from the custom u_contract_sla_config table).ResolutionThis behavior is a defect in the Platform and is discussed in PRB1403785. A workaround is available on-demand, and the behavior is permanently fixed in the Paris family release. What was happening is that, prior to New York, if a SLA Definition table contained a "Class" ("sys_class_name") field, SLA processing limited the query on the SLA Definition table to records where sys_class_name=contract_sla (this was to exclude "Service Offering SLA Definitions" which are an extension of the contract_sla table and are introduced by plugin "Service Portfolio Management - SLA Commitments").In New York, the "Service Portfolio Management - SLA Commitments" plugin was re-worked so that it no longer included a table extension, and instead, a Service Offering SLA Definition was defined just by ticking a new checkbox labeled "Service commitment" and the service_offering_sla table was deprecated.However, this meant the method to query for SLA Definitions needed to be changed, and this is where the change in behavior was introduced.The query is no longer automatically limited on the SLA Definition (contract_sla) table to records where sys_class_name=contract_sla and so this is why on the user's Orlando and New York instances, SLA processing is also finding the SLA Definition records in the u_contract_sla_config table.