> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/sandbox/integration-dependencies/release-notes.md).
# Release Notes
\
These release notes describe recent changes to Harness Feature Management & Experimentation (FME).
**Last updated: September 25, 2026**
{% updates format="full" %}
{% update date="2026-09-25" %}
## Dart Client SDK and OpenFeature Provider are now available
Harness FME now provides a Dart Client SDK, [`splitio_client_side`](https://pub.dev/packages/splitio_client_side), giving Dart and Flutter developers a way to add feature flags and experimentation directly into their applications. The SDK runs on the Dart VM and Flutter across every target platform (Android, iOS, Web, and Desktop), and is pure Dart with no `dart:html`, `dart:io`, or `dart:ffi` dependencies, so it works anywhere Dart or Flutter runs.
Harness FME also provides [`split_openfeature_provider_dart_client`](https://pub.dev/packages/split_openfeature_provider_dart_client), an OpenFeature provider that wraps the Dart Client SDK. With the Dart OpenFeature Provider, teams can:
* Evaluate Harness FME feature flags through the standardized, vendor-agnostic [OpenFeature](https://openfeature.dev/) client-side API instead of FME's native SDK API
* Register the provider with a single `SplitFactory` instance and call `OpenFeatureAPI.instance.setProviderAndWait()`
* Evaluate flags with the standard `getBooleanValue`, `getStringValue`, and related OpenFeature client methods
**Related documentation**
* [Dart SDK](https://developer.harness.io/feature-management-experimentation/new-to-fme/sdks-and-customer-deployed-components/client-side-sdks/client-side-standard-sdks/dart-sdk)
* [OpenFeature Provider for Dart](https://developer.harness.io/feature-management-experimentation/new-to-fme/sdks-and-customer-deployed-components/openfeature-providers/dart-sdk)
{% endupdate %}
{% update date="2026-08-21" %}
## Jira Cloud integration for US and EU accounts
Harness FME now provides Jira Cloud integrations for US and EU accounts through the [Atlassian Marketplace](https://marketplace.atlassian.com/vendors/1221408/harness-inc). These Forge-based integrations replace the **Split for Jira** integration and are now the primary way to connect Harness FME with Jira Cloud.
Use the Marketplace integration for Jira Cloud installations that corresponds to your Harness account region: [Harness FME - Standard](https://marketplace.atlassian.com/apps/1723796743/harness-fme-standard) or [Harness FME - Europe](https://marketplace.atlassian.com/apps/636403565/harness-fme-europe).
With the Jira integration, teams can:
* Associate Harness FME feature flags with Jira work items
* Create feature flags from Jira work items
* Link existing feature flags to Jira work items
* View feature flag and Jira work item associations from either platform
* Navigate between Jira and Harness FME
**Related documentation**
* [Jira Cloud](/feature-management-experimentation/management-and-administration/integrations/jira-cloud.md)
{% endupdate %}
{% endupdates %}
### August 2026
#### FME Metric Check Step in Harness Pipelines
***
**2026-08-18**
Harness FME now supports the **Metric Check** step in [Harness pipelines](/feature-management-experimentation/management-and-administration/pipelines.md), allowing teams to evaluate a [feature flag metric](/feature-management-experimentation/use-fme/experimentation/experiment-results/viewing-experiment-results/index.md#viewing-metrics) during a pipeline execution and automatically gate rollout decisions based on the result. The step also exposes metric and evaluation details as pipeline outputs, allowing downstream steps to reference the results if needed.
The **Metric Check** step retrieves a metric, evaluates it against user-defined failure criteria using JEXL expressions, and returns a pass or fail result. This enables release monitoring workflows where a pipeline can automatically continue, pause, roll back, or trigger another failure strategy based on live application metrics instead of requiring manual verification.
This step is available under **Feature Management & Experimentation** in the [Harness pipeline step library](/harness-platform/use-harness-platform/pipelines/add-a-stage.md#steps-available-for-custom-stages) and can be combined with existing pipeline capabilities such as approvals, notifications, and failure strategies to validate error rates, latency, conversion rates, or other key metrics after a deployment before continuing a rollout.
**Related documentation**
* [Using Feature Management & Experimentation with Harness Pipelines](/feature-management-experimentation/management-and-administration/pipelines.md#metric-check)
#### Scheduling in the Change Requests API
***
**2026-08-11**
The [Submit Change Request](https://docs.split.io/reference/create-change-request) API now supports scheduling. When submitting a change request for a feature flag or segment, you can include `scheduledFor`, a Unix timestamp in milliseconds marking the exact date and time an approved change executes, rather than having it execute immediately upon approval.
The two new fields, `scheduledFor` and `scheduledForTimezone`, are shown below. This example is abbreviated to highlight the new fields; a full UPDATE request also includes the existing `split` definition, as shown in [Schedule a change request](/feature-management-experimentation/management-and-administration/api-best-practices/approvals.md#schedule-a-change-request).
```json
{
"operationType": "UPDATE",
"title": "New rollout split percentage",
"comment": "updated rollout percentage",
"approvers": [],
"scheduledFor": 1786201200000,
"scheduledForTimezone": "America/Los_Angeles"
}
```
`scheduledFor` is an absolute point in time and is not affected by time zone. Optionally include `scheduledForTimezone` to control the time zone used to display that scheduled time in the Harness FME UI, for example to approvers reviewing the pending change; it does not shift when the change executes. If omitted, Harness FME displays the scheduled time in `UTC`. The value must be a valid IANA time zone identifier, such as `America/New_York` or `Europe/London`; invalid time zones are rejected.
Change requests submitted with scheduling also follow a distinct status lifecycle: a pending scheduled change request reports `SCHEDULE_REQUESTED` instead of `REQUESTED`, and moves to `SCHEDULED` (instead of `APPROVED`) once approved, remaining there until the scheduled time arrives and the change publishes.
**Related documentation**
* [Approval Flows and Change Requests](/feature-management-experimentation/management-and-administration/api-best-practices/approvals.md#schedule-a-change-request)
* [Submit Change Request API](https://docs.split.io/reference/create-change-request)
### July 2026
#### Bucketing keys in Amazon S3 Exports
***
**2026-07-21**
Harness FME now includes a `bucketingKey` column in Amazon S3 impression exports. When your SDK provides a bucketing key for feature flag evaluations, that value appears in the `bucketingKey` column of the exported CSV. This makes it easier to analyze account-level rollouts, validate consistent treatment assignment across users, and support multi-tenant experimentation workflows.
```csv
key,label,treatment,splitName,splitVersion,properties,environmentId,trafficTypeId,sdk,sdkVersion,machineName,machineIp,timestamp,receptionTimestamp,bucketingKey
user_alice,default rule,on,new-dashboard,42,,prod,user,ruby,8.3.1,app-server-1,10.0.0.15,1783065571253,1783065598653,acct_abc123
user_bob,default rule,on,new-dashboard,42,,prod,user,ruby,8.3.1,app-server-1,10.0.0.15,1783065588095,1783065598653,acct_abc123
user_charlie,default rule,off,new-dashboard,42,,prod,user,ruby,8.3.1,app-server-2,10.0.0.16,1783065592000,1783065600000,
```
The `bucketingKey` column is optional and remains empty for SDK evaluations that do not provide a bucketing key.
**Related documentation**
* [Amazon S3 Integration](/feature-management-experimentation/management-and-administration/integrations/amazon-s3.md)
* [How Bucketing Works](/feature-management-experimentation/use-fme/feature-management.md#ensuring-a-consistent-user-experience)
{% @harness-feedback/feedback module="release-notes" pagePath="release-notes/feature-management-experimentation" %}