Features

We already described what an object is, and a few examples of objects. Every object type has a set of basic fields of information that describe the object itself. For example, the contact object is described by name, email address, password.

A feature is a specific functionality or trait that extends the data associated with an object, making it more functional.

For example, tags are one of the features supported by objects such as contacts. Workflows is another example of a feature, and it is supported by objects such as deals or orders.

The features that are supported by an object are system-defined.

 

Each feature is described with greater detail in the features chapter of this guide, but some of the most important are the following.

 

Attributes and attribute groups.

As mentioned earlier, every object type has a set of basic fields of information that describe the object itself. Many object types support the addition of custom attributes to extend the way they are described, according to your very own needs. For example, a contact could have a favorite-color attribute; or a story could have an author attribute.

Attribute groups are a means to organize attributes in the user interface so that attributes belonging to the same group appear together. Attribute groups are user defined.

Attributes and attribute groups can be managed through their corresponding applications accessible from the main menu.

 

Taxonomies

Taxonomies are a hierarchical structure that allows you to classify objects in a great number of ways. You don’t need to use hierarchies but this adds a lot of possibilities to classify your data.

For example, you could use taxonomies to classify your ecommerce products by brand and sub-brand. You could create a root taxonomy called brand under which you would create a taxonomy for each brand, and each brand would have its sub-brands as children.

Another example would be using stories to describe online courses. Taxonomies could be used to classify each course in basic, intermediate or advanced, or to classify them by required or optional. 

Taxonomies can be managed through its corresponding application accessible from the main menu.

 

Segments and collections

Segments or collections are, as the name implies, logical groupings of objects of the same type that share a common attribute or trait. Although both terms are interchangeable, segments is more appropriate for groups of contacts, and is widely used in the marketing industry, whereas collections applies to everything else.

Segments and collections are created by specifying a set of conditions that the object needs to meet to be considered part of the collection. Whenever an object changes, if the changes cause the collection’s rules to be met, the object will be automatically added to the collection without any manual intervention. Likewise, if the changes cause the collection’s rules not to be met, the object will be removed from the collection.

Segments and collections can be managed through their corresponding application accessible from the main menu, but also directly from the segments/collection filter in the explorer bar<link: explorer bar>.

 

Templates

Some object types, such as stories and locations, are associated with their corresponding templates (story templates and location templates). 

An object template is an object itself, and represents a blueprint of the data that should be supplied with the objects associated with that template. The purpose of a template is to facilitate the input of data by prompting for the information that makes sense for a particular object. An object type can have more than one template.

For example, you could use the story object to model blog posts, events and courses. 

You typically define attributes that you would need, for example you would need an author attribute for a blog post, you would need a location and cost for an event, and you would need cost and course-pdf for the courses. 

Then you would create three different story template objects, and each template would define which information is needed for which object. The author attribute would be included in the blog post template, but it wouldn’t make sense to include it in the event template. 

Later when creating a story of a certain kind, let’s say a blog post, the interface would only ask for the information that makes sense for the blog post, and would not ask for information related to any other kind of story, thus enhancing the user experience.