{"version":"2.1.232","anchor":"managed-settings-policy-helpers-can-carry-a-static-fallback-","canonical_anchor":"managed-settings-policy-helpers-can-carry-a-static-fallback-","heading":"Managed settings: policy helpers can carry a static fallback payload","tier":"use","area":"Managed Settings","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232\/e\/managed-settings-policy-helpers-can-carry-a-static-fallback-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.232","markdown":"### Managed settings: policy helpers can carry a static fallback payload\n\nAdmins can attach a static `defaultSettings` payload used when a policy helper is missing or fails.\n\n**What**\n\nAdmin policy sources can now put a `defaultSettings` payload on each per-OS entry of `policyHelpers` (or under a top-level `default` key). If no helper is configured for the platform, or the helper fails at startup or on a refresh, that payload is applied with no process spawned instead of the previous retain-or-fail behaviour.\n\n**Details**\n\n- Failures are logged as \"applying the static ... settings payload\" and counted in the `settings_policy_helpers_per_os` telemetry as `fell_back_to_default_on_failure` or `refresh_fell_back_to_default`.\n- A payload that does not parse is reported as `default_payload_invalid` and refuses startup.\n- If a helper later recovers on a refresh tick, its output replaces the static default.\n- Putting `defaultSettings` on the singular `policyHelper` key is ignored and produces a status warning saying static fallback payloads belong on the per-OS `policyHelpers` entries.\n\n**Evidence**\n\n`fell_back_to_default_on_failure`, `policyHelper refresh: helper recovered; its output replaces the static default settings payload`\n\n- Area: Managed Settings\n- Names: `policyHelpers`, `defaultSettings`, `default`\n- Tier: Use it now\n- Useful: 3\/5\n- Signal: 3\/5"}