The Interface Builder’s workflows not only let enterprises specify the teams for creating working copies and publishing them. Furthermore, you can define constraints to restrict the website area or the kind of content the teams should work on. If a workflow doesn’t have such constraints, the teams simply aren’t restricted and can add, delete or change content as they wish.

A workflow’s content constraints consist of a list of permits. Any number of permits can be specified, and every additional permit broadens the scope of actions the teams can take.

A permit consists of one or more attribute-related conditions a content object must meet to be editable in the context of the workflow. If more than one condition is specified in a permit, all of them must be met for the permit to be effective. Optionally, a condition can be negated.

Here are some examples:

As the field of a condition, the built-in attributes _obj_class, _path and _site_id as well as all custom attributes of the string, stringlist, enum and multienum types can be specified.

Next to the equals operator, starts_with and is_inside_subtree_of are available, but only in connection with the _path attribute. starts_with checks whether an object is located directly or indirectly underneath a specific parent object, i.e. belongs to a specific section of the page hierarchy. is_inside_subtree_of does the same but expects the value to be an object ID, not a path prefix.

If, in the second and last example above, the object with the specified ID doesn’t have a path, is_inside_subtree_of is true for this object only.