Define Published Attributes
Published Attributes can be defined in multiple ways and must be defined before any values can be published or used. All parameters are described below along with each way Published Attributes can be defined.
Published Attribute Parameters
Parameter | Description | Required | Mutable |
---|---|---|---|
Attribute Name | Each Published Attribute name must be unique across all Published Attributes. The name can be changed, but care should be taken if new values are passed into our system by name. See Publishing New Values. Dot notation can also be used in the name. See notes below for details. | True | True |
Data Type | The data type may be one of: String, Integer, Decimal, Boolean, Date, Timestamp. All values for a given Published Attribute must have the same type, so the type cannot be changed once the attribute is created. | True | False |
Default Value | The Default Value must be defined. It will be provided when a Published Attribute value is requested for an Entity, but either no value has ever been published for that Entity or a previous value was published but has since expired. | True | True |
Default Value Note | An optional note about the default value. It can describe, for example, how the default value is expected to be used in a workflow. | False | True |
Description | An optional general description for the Published Attribute. | False | True |
Contains PII | Indicates if the Published Attribute contains PII information. If so, we will hash and encrypt all values and will not store the raw values at all. The default value is False. | True | False |
Expires In | A Published Attribute can be set to expire in a given number of days. For example, a client might want to only treat a credit score value as valid for a certain period of time. If/when a value expires, it will no longer be used and the default value will be provided instead. | False | True |
JQ filter | Any JQ filter value provided here will be applied to all incoming values that should be published in the system, regardless of how they are received. See details at Published Attributes and JQ. | False | True |
Token | The token is not specified by the user, but is assigned automatically by the system when a Published Attribute is first defined. This token is what is used to identify a Published Attribute when using the /published-attributes API. It is listed on the Published Attribute Settings page. | False | False |
Published Attributes Containing PII
Alloy cannot independently determine if a Published Attribute contains PII or not, so we rely on our clients to provide this information. The Published Attributes can be used in the thresholds of workflows, but since we do not store the raw values, the only valid operators you can use in comparisons with them are equal or not equal.
Dot Notation in a Published Attribute Name
We strongly encourage you to publish new values using the /published-attributes API as explained in Publishing New Values. However, there may be circumstances where you need to send in new values via the /evaluations or /entities APIs (also described on that page). For both of those APIs, we will automatically detect any Published Attributes in the payload, according to the name of the Published Attribute.
Since it can be useful to nest values in a JSON payload, we allow you to use dot notation in the Published Attribute name - e.g., meta.customer_income. We will look in exactly the place that is indicated by the name and only that place. Using the /entities API, we only allow Published Attribute values to be provided under the meta object, so if you want to publish new values using both of these endpoints, you will need to use a Published Attribute that begins with meta.
The other implication of this is that, if you want to send in values using batches, any column name that corresponds to a Published Attribute must also use exactly that name, including the dot notation. Again, with all of these options, we encourage you to just publish new values via the /published-attributes API, but we provide these other possibilities in order to accommodate special circumstances.
Changing a Published Attribute Name
It is possible to change the name of a Published Attribute because the Published Attribute token is what makes it unique, not the name. Though it is possible, we do not encourage it and expect it will be done very infrequently.
All attribute names within a given workflow must be unique, so before allowing a name change, we check every workflow where the Published Attribute is used to ensure the new name will not create any conflicts. If it is not unique, you will need to either use a different name or change the existing attributes in any conflicting workflows.
Settings Page of the Dashboard
Published Attributes can be defined and updated via the Settings page of the dashboard.

When you define a Published Attribute via the Settings page of the dashboard, the modal, as shown here, guides you through defining each of the parameters, noting those that are required with a red asterisk, or those that cannot be updated when modifying an existing definition.
Some parameters have default values, so they only need to be specified if the value should be changed - e.g., if a Published Attribute contains PII. The Default Value parameter is a special case of this. For most data types, a default value must be provided, but for string Published Attributes, an empty string is automatically defined as the default value unless it is changed.
Once a Published Attribute has been defined, the assigned token is also displayed when viewing the definition via the dashboard. This token is required to communicate with the /published-attributes endpoint.
Archive Published Attributes
From the Settings page, you will see the full list of all defined Published Attributes. From that list, using the 'More' options to the right of each attribute, you can edit or archive them. Published Attributes can only be archived through the dashboard.
Published Attributes can be archived, and if needed, they can also be unarchived at a later time. Archived Published Attributes cannot be added to workflows and, if new values are received for them, those values will not be published, though all previously existing values will be retained. You are not allowed to archive a Published Attribute that is in use in an active workflow. If you try, the system will show you the active workflows where it is currently in use and you will need to remove the attribute from all of the listed workflows before you can archive it.
Via the /published-attributes Endpoint
Published Attributes can also be defined via the /published-attributes endpoint. All required parameters must be specified. The Default Value must also be specified, even when the data type is 'string.' See the Published Attributes API documentation for details.
Define From a Workflow
Published Attributes can be used in a workflow as either Input Attributes or Output Attributes. For ease of configuration, when adding a new attribute of either kind to a workflow, you can also decide to publish the attribute at the same time using the 'Publish this attribute' option. If you do, additional fields will be available in the modal so that you can complete the Published Attribute definition. Then you can add the attribute and publish it in one step. See more details at Input Attribute Usage and Output Attribute Usage.
Updated over 1 year ago