As explained in the core concepts section, release toggle is a mechanism used to control features' visibility.
Let's see how to create your first awesome release toggle. Click on the Release Toggle section on the sidebar.
Enter the name of the feature; you notice that the key will be complete automatically. The key must be unique in the project, is the way Koople identify your release toggle. If the key already exists, the platform will throw an error message when trying to create it, and the key must be changed to complete the process. Optionally, you can add a description to your release toggle.
Try naming your release toggle with descriptive names. For instance "Social login button", the key will be automatically filled as "social-login-button". This naming will help you when coding, improving human readability.
When a release toggle is created, it is replicated in all the same project environments in a disabled state by default. Similarly, when we create a new environment, it will already have all the release toggles created in the same project's other environments.
Pay particular attention to the "Server Only" checkbox. The release toggles (and remote configurations) marked as Server Only will be evaluated only by the server SDKs, never by the client SDKs. The main reason is that, for example, you may want to provide confidential information (for example, some configuration keys). For this reason, we will prevent it from appearing outside of trusted environments such as a web browser.
Release toggles are short-lived features. We have set a maximum of 30 days (somewhat subjective but we have pulled high) to display an alert on the panel.
To disable the alert, it would be enough to mark the feature as Long-live (kill-switch is an example of a long-live feature).
Release toggles have three possible states:
Disabled: Default state on creating. That state means that the feature is disabled for all users.
Soft Released: The feature is enabled for certain users. We will go into detail below.
Released: The feature is enabled for all users.
Disable and Release states are quite easy to understand: visible or not visible; enabled or disabled. But, when we are developing new features, we want to access our new feature. Initially, maybe it's enough if only the developer has access. Still later, we need to give access to other team members like other developers, QAs or even business people.
The soft release has different ways to identify the users that will be able to access the feature. The most direct way is just setting the user identifier; that identifier is how your application identifies the user. For example, if the users are identified by the email just put the allowed users' email on the identities input.
The user identifier is whatever your application use to identify the users. It can be an internal id, an email address, a username...
However, identifying users by identities may not be enough, especially when identifying user groups. For these cases, we will need to add identification rules. These rules are simple logic operators like exist, is one of, greater than, etc.