Reduce servers noise in ML Candidates flowBackground: The Candidate Lifecycle job validates accuracy and relevance of candidate records by identifying non valid servers. This feature should ensure recalculation of candidates built on top of non valid servers to make sure they are removed from the service candidates. Before the August version 2025 SP+ 1.16 the flow used following properties to filter out not operational servers: "sa.inactive_install_status" the default value is "100" (Absent) -- the servers with Install Status "Absent" will be not used or removed from candidates. "sa.active_operational_status" the default value is "1" (Operational)-- the servers with Operational status "Operational" will be used for candidate flow. The properties are not visible in sys_properties and in case system property does not exist, the default value will be used. All servers with "Operational" status and not "Absent" Install status will be used for candidate flow. The Candidates with servers that become not operational will be sent for Recalculation and Recalculation job will remove these servers from candidates. In case server will be switched to be Operational the Candidates won't be restored till the Traffic data will be updated for relevant processes and the servers will be sent to Build candidate process. After the August version 2025 SP+ 1.16 the following properties were added for Candidates flow: "sa.inactive_operational_status" the default value is "6" (Retired) to handle list (blacklist) of Retired (non-reversible) operational statuses. This property is not visible in sys_properties and in case system property does not exist, the default value will be used. "sn_sm_scoped_app.max_valid_discovery_period_in_days" the default value "0" (Disabled) to handle period to consider server as Retired/Not recently discovered This property is visible in sys_properties and has the default value. The flow resolves the two properties "sa.active_operational_status" and "sa.inactive_operational_status" to get an Active Operational status. For example if the both properties have "6" (Retired) value, the Retired servers will be stay in candidates. Customer can provide multiple values for both properties separated by comma. After changing the properties the Candidate Lifecycle job will check all candidates and mark the relevant candidates for Recalculation and Recalculation job will remove non valid servers from candidates. In case server will be switched to be Operational the Candidates won't be restored till the Traffic data will be updated for relevant process and server will be sent to Build candidate process. "sn_sm_scoped_app.max_valid_discovery_period_in_days" (Integer) can help to customers to filter out servers from candidates that are not discovered for some period of time.(number of days since last discovery) After changing the properties the Candidate Lifecycle job will check all candidates and mark the relevant candidates for Recalculation and Recalculation job will remove not discovered servers from the candidates. In case the server will be discovered the Candidates won't be restored till the Traffic data will be updated for relevant process and server will be sent to Build candidate process. In case some property was changed by mistake, customer can restore the candidates by removing the following properties from "sa_ml_internal_properties" table: "sa_asc_p2p_table_index" "sa_asc_p2p_ext_table_index" After then customer should wait till all candidates will be rebuilt.