Features

You can create features of the following types:

The feature key is the reference you use in your application, when you use the SDK, you can check the value of a feature, referencing the feature key. It must be unique for your application. For example "FEATURE_LANDING_PAGE"

When you add a feature flag, this will also automatically create a feature value in each environment. The default feature value will be set to off for boolean type and to null for string, number and json. By default, each feature value will be locked. Essentially feature value is always associated with an application and an environment for that application.

This field can hold a feature description, max 300 characters.

This field can hold a link for example to your task management system, e.g. Jira or Azure DevOps.

The intention of this field is to store additional information that you may need to provide about your feature, for example when you want to access this information from your CI/CD pipeline. This could be JSON string, simple string, property entries or other types of data. It is stored as a string and has no data limit (stored as CLOB). Metadata field can be accessible once feature is created from the Edit menu.

When feature flag is not needed any longer in your application, and you are ready to remove it, you can first "retire" this feature in a single environment to test how your application behaves, by setting it to the "Retired" state. This means that the feature won’t be visible by the SDKs, imitating the "deleted" state. You can always "un-retire" a feature if you change your mind as this operation is reversible. Once you retire feature values across all the environments and test that your application behaves as expected, you can delete your entire feature. Deleting a feature means it is completely deleted from the system for all environments. This operation is not reversible. To retire a feature you will need environment specific "CHANGE_VALUE" permission. To delete a feature, you require an application specific permission to create, edit and delete features.

Locking provides an additional safety net per environment when deploying incomplete code into production. It locks a feature, so its value can’t be changed for a given environment. Typically, developers keep features locked until they are finished and ready to be set, for example when they are ready to be tested in one of the test environments. Another use case for feature locking would be when developers or testers keep it locked in production environment, indicating to release management team that it is not ready to be turned on. Only groups or service accounts with LOCK/UNLOCK or CHANGE_VALUE permission can lock or unlock the feature value. CHANGE_VALUE permission supersedes the LOCK/UNLOCK.

Last updated status is available on each feature and displays "When" updated and by "Who".