Custom properties allow you to expose any of your application properties to CloudBees Feature Management and then use these properties as a criteria for feature releases. Custom properties can be used either in Target Groups or in the Audiences tab as a criteria for feature release.
For example, if you want to open a feature only for internal employees, the way you can identify internal employees is by the email domain they have (e.g: @cloudbees.com). In this example you would define a custom property called
You can create your own custom properties that can be used when defining Target Groups or in the Audience tab as a criteria for feature release. Custom properties can be created either from the code or the dashboard. If you add a custom property to the code and run/compile the application they will automatically be available in the dashboard.
Explicit property is a Custom Property which is defined entirely within your code by using the CloudBees Feature Management API. The SDK supplies a function for every type of property. The available property types are as follows:
The type Number is used in some platforms instead of Double and Int.
Once the above code is running you will be able to use the Custom Property from within the CloudBees Feature Management dashboard.
The following are examples of how to define Explicit Custom Properties in the code on different platforms:
The value of that Custom Property is defined by the DynamicPropertiesRule in the code.
The Dynamic Custom Property Rule handler is called when an explicit Custom Property definition does not exist on the client side.
If you do not set the setDynamicCustomPropertyRule it will then activate the default function which tries to extract the property value from the context by its name.
A generic implementation of that handler can be described by the following snippet:
(propName, context) => context ? context[propName] : undefined
The following examples are code snippets to create this rule on different platforms:
SDKs 5.0 or later
As mentioned, you can also define custom properties in the dashboard. To add a custom property from dashboard: . Go to CloudBees Feature Management dashboard. . Go to App Settings > Custom Properties. . Scroll the to the bottom and click Add new Custom Property
|You would still have to add the custom property to the codebase for it to actually work.|
You can change your Custom Property in the dashboard instead of changing your property in the code. For example, if you defined a Custom Property of type Int, you can change the type to String in the dashboard.
To change Custom Properties, do the following:
Go to CloudBees Feature Management dashboard.
Go to App Settings > Custom Properties. See a list of Custom Properties.
Click on a Custom Property from the list to change. The Update Custom Property window pops up.
In the Update Custom Property window:
Change the type.
Add a description
Since custom properties are added to the code, to prevent code < > dashboard discrepancies, custom properties cannot be deleted. Custom properties can however be hidden, which means they would not be available in the Target Group screen or in the inline targeting on the audience page.
|You can still hide a custom property even if it’s been used.|
To hide or unhide a custom property: . Go to CloudBees Feature Management dashboard. . Go to App Settings > Custom Properties. . View the list of Custom Properties. . For each custom property there is a corresponding drop down menu to select if this property is visible or not. Click on the dropdown to change custom property visibility.
Servers handle requests from multiple users as opposed to client applications that are built for a single user.
Sometimes the flag value might be related to the context of the call and will need additional information (in order to be evaluated correctly) which is available only at the time the flag is checked. For example, a flag value may only be determined once a user is authenticated.
This feature is only available for the following SDKs
Server side SDKs:
Client side SDK:
Context is an object that is provided to a flag in order to evaluate the flag correctly for the specific call. Here is how you create a context:
Context keys are
String’s and values can be any type that is required in order to evaluate the flag correctly.
When checking the flag value, the flag expects a context object that will be used for the evaluation.
Experiments and the configuration audience are configured using Target Groups. Now that the context has been defined, continue reading to learn how to use the context in properties.
Target Groups let you define your audience based on properties. Property value can be different based on the context it receives. For example, we can define property that will be true for users with items in their shopping cart.
With this property, we can target all users which have items in their
shopping cart and offer them a special discount. As you can see, the context that we passed to
will be used to calculate the value of the
property specific for this user.
What do you do if there is one or more key-value which should be the same for all property calculations? For this case, we have the global context.
You can think of global context as a default context. Whenever the context that is passed to a flag is missing something that is required for property calculation, if this information exists in the global context, it will be available for the property. Creating a global context is exactly the same as a regular context. The only difference is that you need to create it and set it properly when the SDK initialized.
As a developer, you don’t need to worry about multiple contexts. The SDK ensures that the context that is passed to properties will include key-values from the local context and also from the Global Context.
In a case where a key exists in both contexts, the key-value from the Local Context that is the one that will take precedence.
rox.distinct_id is a default Custom Property that comes out of the box
and is used internally by the system for splitting values by percentage
(in the experiment audience screen). On client side SDKs
rox.distinct_id is automatically generated and
stored locally, this is important in order to create a consistent user
behavior when running an experiment with split values.
On the server side, it is the developer responsibility to supply a consistent string value that can be used for percentage splitting.
In this example below, we have chosen the userId as the value to be used for percentage splitting.