Add identity_override_ids Field to Webhook Payload for Managing Identity-Specific Flag Overrides

[Alyahya-A]

Is your feature request related to a problem? Please describe.

Hello,

Description:
We use Flagsmith in a microservices architecture with real-time feature flag updates managed through webhooks. However, we face challenges differentiating between global flag updates and updates that affect only specific identities with overrides.

Problem Statement

Currently, the webhook payload does not provide enough information to determine:

1. Whether a flag update is a global change that should apply universally or a specific override for certain identities.
2. Which identities have specific overrides on a given flag when a global update occurs.

Example Scenarios:
A feature flag (FlagA) has identity-specific overrides (e.g., disabled for one identity and enabled globally). When FlagA is updated in the dashboard at the global level, the webhook event sets identity_identifier to null, which does not indicate if FlagA has identity-specific overrides.

In this scenario, there’s ambiguity in determining if the flag has identity overrides without directly querying Flagsmith again. It would be beneficial to know if the current update impacts all identities universally or if it excludes identities with overrides.

Describe the solution you'd like.

Proposed Solution

• Add a new field identity_override_ids to the webhook payload, which provides a list of all identity_identifier values that have specific overrides for the updated flag.
• Usage:
  • When identity_identifier is null, identity_override_ids provides a list of all identities with overrides, allowing services to determine if they should apply the global update or ignore it if their identity is in the list.
  • When identity_identifier is not null, it indicates that the update is for that specific identity, and other identities can ignore the event.

Example of Proposed Webhook Payload Enhancement

{
    "feature_segment": null,
    "feature_state_value": "Test",
    "identity": null,
    "identity_identifier": null
    "identity_override_ids": ["IdentityX", "IdentityY"]
}

Describe alternatives you've considered

• Querying Flagsmith to Retrieve Override Information: One alternative is to make an additional API call to Flagsmith after receiving a webhook to check for any identity-specific overrides on the updated flag. However, this approach increases latency and API call overhead, especially in a microservices environment with multiple webhook recipients.

• Using Tags to Identify Microservices: Another option is to incorporate tags to manage microservice-specific flags. If Flagsmith's .NET SDK could support retrieving flags with tags and if tags were included in the webhook payload, this would allow us to filter and retrieve only the flags relevant to a specific microservice, reducing unnecessary data and ensuring accurate flag configuration for each service.

Additional context

No response

[matthewelwell]

Hi @Alyahya-A , unfortunately, querying this data can be quite intensive since it is feasible to have large numbers of identity overrides on any given feature.

Could you change the issue into a problem statement, including more information about your use case, rather than suggesting a solution?

Specifically, I would like to challenge this statement:

It would be beneficial to know if the current update impacts all identities universally or if it excludes identities with overrides.

Why is that beneficial? What are you planning to use that information for?

I'm also unsure regarding this statement:

Whether a flag update is a global change that should apply universally or a specific override for certain identities.

From what I can tell, the information in the webhook should be sufficient for you to determine this. The identity_identifier field will be filled for a change related to a specific identity, but null for a global change.

[Alyahya-A]

Hi @matthewelwell,
Thanks for the response and for the opportunity to clarify our use case further.

Problem Statement

Our system relies on identity overrides for configuring feature flags per entity. We receive webhook events from Flagsmith for flag updates, but the current webhook payload lacks details to handle identity overrides effectively in our case.

Use Case & Benefits

Each microservice acts as a distinct identity in Flagsmith with its own flag overrides. This use case extends beyond microservices to any setup with identity-specific configurations. When we receive a flag update, we need to determine if it:

1. Applies universally to all identities (a global change), or
2. Excludes certain identities with specific overrides, preventing the global change from applying directly.

This clarity is essential for two reasons:

1. Avoid Overriding Identity-Specific Configurations:

   • Without knowing if a flag has identity-specific overrides, we risk overriding custom configurations. Querying Flagsmith to verify overrides for each global update adds latency and system load, especially in multi-identity environments.

2. Efficient Event Propagation:

   • If identities with overrides are known, we can target updates efficiently, if the update is global change we can ignore identities with overrides to get this update, minimizing redundant processing across services.

Current Limitation in the Webhook Payload

Currently, when a global change occurs, the identity_identifier field is set to null, which helps differentiate it from identity-specific updates. However, if a flag update is global, there is no indication of whether any identity-specific overrides exist for that flag. Without this data, this update will be applied to all identities, so it is unclear whether the update should apply to all identities or if identity-specific configurations should prevent it from doing so.

Providing this data in the webhook payload would streamline handling of global and identity-specific updates, reduce redundant API calls, and help maintain accurate flag configurations across services.

[rolodato]

Each microservice acts as a distinct identity in Flagsmith with its own flag overrides

This seems like an unusual case. Do all your microservices share the same feature flags?

Without knowing if a flag has identity-specific overrides, we risk overriding custom configurations

What does "custom configurations" mean?

[Alyahya-A]

Thanks for the follow-up questions! Let me clarify:

"This seems like an unusual case. Do all your microservices share the same feature flags?"

Yes, each microservice shares the same core feature flags, with some flags using identity-overrides to customize behavior without creating separate flags or projects since we have shared flags across microservices.

This need isn’t unique to microservices; any setup with identity overrides would benefit from knowing when a flag update impacts all identities versus specific overrides.

"What does 'custom configurations' mean?"

By "custom configurations," I mean identity-specific overrides that differ from global or segment defaults. For example, one service might have a flag enabled while the global setting is disabled. Without knowing which flags have identity-specific overrides, we risk applying global updates that could override intended configurations.

Let me know if this clarifies, or if there are more details I can provide. Thanks!

[rolodato]

If I understand the use case correctly, you should be fetching the actual state of flags (i.e. perform remote evaluation) after you receive an update event, to see what the final state of all flags is after applying any overrides for the current identity. This is how regular real-time updates work, where it's up to consumers to fetch flags after they receive an update message: https://docs.flagsmith.com/advanced-use/real-time-flags