Harness Feature Flag FAQs

Updated 2 months ago by Archana Singh

This article addresses some frequently asked questions about Harness Feature Flags (FF).

In this topic:

What is a Target and Target Group?

Target is an entity in your application domain on which you want to make a Flag decision. Some examples are end-users or customer accounts.

Target Group is a collection of Targets. For example, Beta Customers, Premium Customers, US Users, etc.

For more information, see Add Targets and Manage Target Groups.

Do I need to add Targets in Harness manually?

No. Targets are auto-discovered as they are used in the Applications when evaluating flags. Here is an example in Java of how you define a target in an application and use it to evaluate the Flag:

     Target target = Target.builder()
.name("User1")
.attributes(new HashMap<String, Object>())
.identifier("user1@example.com")
.build();
.build();
boolean result =
cfClient.boolVariation("toggle", target, false);
log.info("Boolean variation is " + result);

For more information, see Java SDK Reference and Add Targets.

What is the difference between client-side and server-side SDKs?

  • Server SDKs are supposed to be used in a trusted environment, like servers or Kubernetes pods. Server SDKs sync Flag rulesets in the background and keep an in-memory cache. When an application makes the call for Flag value, the evaluation happens locally, and no network call is made. Hence it is very fast and efficient.
  • Client SDKs are designed to work in a non-trusted environment, like user browsers or Mobile phones. Feature evaluation happens on the server-side, and SDK only gets the evaluated results of the Flags.

For more information, see Client-Side and Server-Side SDKs.

How does the streaming mode work?

Streaming provides a persistent connection to the SDKs. Harness Feature-Flags uses Server-Sent Events to send messages to the servers whenever the feature flag rules change. This has the following benefits:

  • Updates flag in a few hundred milliseconds.
  • Avoids any delays by delivering real-time updates to end-users/targets. 
  • Ensures that every change that is made is dispersed to every user in real-time propagating them across every server.

For more information, see Communication Strategy Between SDKs and Harness Feature Flags.

How does the metric aggregate/batch the data before sending it to Harness?

On Server SDK:

  1. On every Flag evaluation, the event is pushed to a RingBuffer.
  2. Evaluation Events are aggregated, Tuple <Flag, Variation, Count>.
  3. Every minute, the aggregated events are pushed to the server.

What happens if Harness Feature Flag goes down?

Harness Feature Flags do not communicate with the SDKs at runtime to decide what to serve a user. They simply used the cached or default state at the time of the session.

Harness availability will have no impact on your application or your users. Every flag has a default state, and the flag states are cached locally on the SDK. As a result, the SDKs will always have a state to serve users if they can not receive any updates on the current flag state from Harness. It will either serve the most recently cached state, or it will serve the default state. 

Where is Flag state evaluated?

The state of a flag is evaluated by the SDK, not on Harness Feature Flag's server. The SDKs are communicated about the state of the flags in the system either through polling or streaming updates from Harness. The SDK then evaluates the flag rules locally based on the current session. The only data communicated back to Harness is the evaluation data - essentially, what state of a flag was served in this session for analytics purposes.

Since the SDKs cache the flag states locally as well, Harness Feature Flags do not need to communicate with the SDKs to serve a session to a user unless the flag state has changed.

Is Feature Flags GDPR compliant? 

While Harness does not yet provide an option for European data residency, Harness Feature Flags are GDPR compliant out-of-the-box and provide teams easy abstractions to remain so in any use case.

The Harness SDKs do not communicate to us any user data that you do not choose to send as an attribute - we do not require or by default send any PII. If any more identifiable customer data needs to be used for flag targeting, it can easily be masked or passed through a custom abstraction layer so that what Harness has is anonymized or not directly traceable back to end-users. Additionally, all data is encrypted in transit.

The most identifiable information that must be stored by Harness in the US, then, is the IP and email address of the actual customer’s team members, and we provide a data protection agreement to cover this data if necessary.

What Happens When Harness Feature Flag Is Unavailable?

Harness Feature Flags do not communicate with the SDKs at runtime to decide what to serve a user. They simply used the cached or default state at the time of the session.

Harness availability will have no impact on your application or your users. Every flag has a default state, and the flag states are cached locally on the SDK. As a result, the SDKs will always have a state to serve users if they can not receive any updates on the current flag state from Harness. It will either serve the most recently cached state, or it will serve the default state. 

What Data Does Harness Feature Flags Receive from the SDKs?

The feature flag SDKs do not send any data that you do not opt-in to send us. The only data communicated by default is an anonymous target identifier so that we can track evaluations. Other than this identifier, all attributes used to evaluate the feature flags by the SDK must be inserted into the code by your team. Harness can receive as much or as little identifying information as you decide is necessary for properly targeting your feature flags.


Please Provide Feedback