Enable 10 Basics

Enable 10 Basics
Enable™ Version 10
Basics
Revised 08/02/2019
• Enable 10.0 Release Enable Suite:

o EnterworksInstallPackage_20190423_1624
o EnterworksDB_20190423_1624
o EnterworksDBScripts_20190423_1624
• Enable Patch:
o EnableServer_10.0_Patch_20190423_1549
• Enable Builds:
o Enable10 10.0.9 Build 20190712_1509
o EnableServer 10.0 Build 20190712_1509
EnterWorks®, Acquisition Inc. a Winshuttle Company

46040 Center Oak Plaza Suite 115
Sterling, VA 20166
Page 1 of 39 Revised 08/02/2019

Enable 10 Basics
©EnterWorks Acquisition, Inc.

Loudoun Tech Center
46040 Center Oak Plaza
Suite 115
Sterling, VA 20166
1.888.242.8356 (Sales and General Information)

1.888.225.2705 (U.S. Support)
http://www.enterworks.com
EnterWorks ® Enable 10 Basics
Copyright © 2007-2019 EnterWorks Acquisition, Inc., a Winshuttle company. All rights reserved.
Law prohibits unauthorized copying of all or any part of this document. Use, duplication, or disclosure by
the U.S. Government is subject to the restrictions set forth in FAR 52.227-14.
“EnterWorks” and the “EnterWorks” logo are registered trademarks and “Enable PIM”, “EnterWorks
Process Exchange” and “EnterWorks Product Information Management” are trademarks of EnterWorks
Acquisition, Inc.
Windows, .Net, IIS, SQL Server, Word, and Excel are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
Java and all Sun and Java based trademarks are trademarks or registered trademarks of the Oracle
Corporation in the United States and other countries.
Oracle is a registered trademark and Oracle 10g is a trademark of Oracle Corporation.

Pentium is a registered trademark of Intel Corporation in the United States and other countries.
JBoss is a registered trademark of Red Hat, Inc.
All other trademarks and registered trademarks are the property of their respective holders.
All icons and graphics, with the exception of the "e." logo, were obtained from West Coast Icons and
Design at http://www.bywestcoast.com. EnterWorks Acquisition, Inc. retains copyrights for all graphics
unless otherwise stated. All other trademarks and registered trademarks are the property of their
respective holders.
This document is furnished for informational purposes only. The material presented in this document is
believed to be accurate at the time of printing. However, EnterWorks Acquisition, Inc. assumes no
liability in connection with this document except as set forth in the License Agreement under which this
document is furnished.

Enable 10 Basics
Table of Contents
1 Document Conventions ...................................................................................................... 5
2 Customer Support ............................................................................................................... 6
3 Overview ............................................................................................................................. 7
4 Introduction ........................................................................................................................ 7
5 Users and Groups ................................................................................................................ 7
5.1 User Password Management ........................................................................................... 8
5.2 Impersonate User ............................................................................................................. 8
6 Data Model ......................................................................................................................... 9
6.1 Data Model Objects.......................................................................................................... 9
6.2 Repositories and Records ................................................................................................. 9
6.3 Profiles ............................................................................................................................ 10
6.3.1 Attributes ............................................................................................................ 10
6.4 Snapshot Tables ............................................................................................................. 15
7 Saved Sets ......................................................................................................................... 15
8 Taxonomies and Hierarchies ............................................................................................. 16
8.1 Types of Taxonomies and Hierarchies ........................................................................... 17
8.2 Taxonomy and Hierarchies Paths ................................................................................... 19
9 Data Model Object Properties .......................................................................................... 20
9.1.1 Properties Repositories ....................................................................................... 21
10 Category/Dynamic Attributes ........................................................................................... 22
10.1 Category Specific Attributes/Category Attributes ...................................................... 22
10.2 Dynamic Attributes ..................................................................................................... 23
10.3 Association Objects .................................................................................................... 23
11 Link Relationships ............................................................................................................. 23
11.1 Linked Records ............................................................................................................ 23
11.2 Linked Repositories..................................................................................................... 24
12 Search Filters ..................................................................................................................... 24
13 Record Validation .............................................................................................................. 25
13.1 Record Validation Example ......................................................................................... 26
14 Staging and Production ..................................................................................................... 26

Enable 10 Basics
15 Promotion and Package Promotion .................................................................................. 27

15.1 Package Promotion in Detail ...................................................................................... 28
15.2 Package Promotion Report ......................................................................................... 30
16 Syndication ........................................................................................................................ 34
16.1 Transmission Options ................................................................................................. 35
17 Channel Readiness ............................................................................................................ 35
18 Digital Asset Management (DAM) .................................................................................... 35
19 Templates.......................................................................................................................... 35
20 Workflow........................................................................................................................... 36
21 Job Scheduling .................................................................................................................. 37
22 Events ................................................................................................................................ 38
23 Security ............................................................................................................................. 38
23.1 User and Group Security............................................................................................. 38
23.2 Attribute and Record Security Filters ......................................................................... 38

Enable 10 Basics
1 Document Conventions
This EnterWorks document uses the following typographic conventions:
Convention Usage
pathnames Pathnames are shown with backslashes, as for Windows systems.
Courier New Denotes sample code, for example, Java, IDL, and command line
font information. May be used to denote filenames and pathnames,
calculations, code samples, registry keys, path and file names, URLs,
messages displayed on the screen.
If italicized and in angle brackets (< >), it denotes a variable.
• Calibri Font (bold) When used in body text, it denotes an object, area, list item, button,
or menu option within the graphical user interface; or a database
name or database-related object. (Examples: the Save button; the
Product tab; the Name field; the SKU repository)
Can also be used to denote text that is typed in a text box. (Example:
Type “trackingNo” in the Name field)
Blue underlined text Words, phrases or numbers in blue are active links that can be
clicked. Clicking these active links will bring the user to the required
information, steps, pages chapters, or URL.

Enable 10 Basics
2 Customer Support
EnterWorks provides a full spectrum of customer support. Check your maintenance contract for
details about the level of support purchased. A customer identification number will be issued
the first time customer support is contacted. Keep this number for future reference when using
the EnterWorks customer support service.
How to reach us Comments
On the Web: For detailed discussions of hardware, software,

configuration issues, or Helpdesk credentials,
https://enterworkssupport.zendesk.com
contact your EnterWorks representative.

Enable 10 Basics
3 Overview
This document captures and organizes basic concepts for managing an organization’s product
information using the Enable® Product Information Management (PIM) system. The Enable
solution is configured for each organization’s unique product requirements; not all functionality
is applicable to every organization.
If a capability or feature described in this document is desired but not available, contact the
Enable account manager or product manager.
For user capabilities, see the Enable 10 Product Information Management (PIM) User Guide.
For administrative capabilities, see the Enable 10 Product Information Management (PIM)
Administration Guide.
For publication capabilities , see the Enable 10 Product Information Management (PIM)
Publication Guide.
For installation guidance, see the Enable 10 Product Information Management (PIM)
Installation Guide.
Specialty multi-media content exists. For more information, contact your Enable account
representative or Enable Product Management team.
4 Introduction
Enable provides organizations the means to define and manage business critical master-data,
related data, and related content. Enable creates a single point of reference to assure
consistent, accurate data is being used by systems and users. Through various integration
methods, data can be imported into the Enable system, validated, enhanced or modified as
needed. Enable can then export or syndicate-out data for use by other business systems.
5 Users and Groups

User accounts are configured in Enable and then the users are assigned to user groups. To
efficiently manage system security, EnterWorks recommends it is managed at the group level,
therefore groups are defined based on system responsibility roles, such as Administrator,
Product Manager, Publications Manager, or Syndication Manager. During configuration, groups
are analyzed and designed to align with an organization’s specific business processes and
operational requirements.
Enable group security defines which functional areas of the application a user is allowed to
view, functions they can perform, and what level of access a user has to objects within Enable
PIM (e.g. code sets, users, groups, repositories, etc.). Each type of object can be configured as
to which groups can create an object of that type, and for existing objects of that type, who

Enable 10 Basics
can read, edit or delete them. For details on the assignment of user and group permissions,
see Security.
5.1 User Password Management

There are three methods used to manage user logins to Enable:
• Local User
• LDAP/LDAPS and Active Directory
• Single Sign-on
If local user authentication is used, an Enable system administrator uses Enable to manage user
passwords. Enable performs all user authentication.
Active Directory is a Microsoft application hosted on an Active Directory server. It manages
user passwords and performs user authentication. The protocol used to communicate with the
Active Directory server is either LDAP (Lightweight Directory Application Protocol) or LDAPS
(Secure LDAP, also known as LDAP over SSL).
If single sign-on (SSO) is used, users access Enable through a corporate login (i.e., on a
corporate web page) and subsequently follow a link to the Enable application. In this instance,
the organization using Enable is responsible for authenticating users.
The local user and LDAP (Active Directory) methods can coexist – some users can be defined as
local while others are defined as using LDAP. If single sign-on is used, then all users must be
authenticated from the corporate login and there cannot be any local or LDAP (Active
Directory) users.
5.2 Impersonate User

The Impersonate User capability allows a user with proper credentials to impersonate another
role to carry out Enable tasks using the roles’ security credentials. The actions of the
impersonator are logged and auditable.
Example Use Case: The security database could have multiple roles, one of which is a
Manufacturer role whose members can load and view data in Enable. A user with the proper
level of security may impersonate a Manufacturer, in which case they would only have the
permissions of a Manufacturer and any action they take would be logged as having been
performed by a member of the Manufacturer group.
Note that the impersonator must have read access for the users they impersonate. Also, for
security reasons, users who belong to an Administrator group are prevented from being able to
impersonate a System Administrator.

Enable 10 Basics
6 Data Model
6.1 Data Model Objects
The Enable data model is comprised of the following objects, which are described in more detail
in following sections.
• Repository – storage for a collection of data; a database table. A repository holds only
one type of information.
• Record – storage for information about one item in a repository; a database table’s row.
• Profile – defines the structure (schema) of records in one or more repositories.
• Attribute – a field in a record that stores information about the item defined in the
record, such as the item’s price or color; a database table’s column.
• Code Set – defines a list of possible values for an attribute.
• Link Relationship – defines a relationship between the records of two repositories or
more, such as a link from a product record to a source record.
• Snapshot Table – a database table that is used to store attribute values that need to be
accessed quickly.
• Sequence - Defines a sequence used by repositories to auto-generate sequence value
for an attribute.
6.2 Repositories and Records

Enable can be configured to have multiple repositories. Each repository is designed to hold
only one kind of data. For instance, a repository might hold information about all the
company’s products or contact information for all their customers, but not both. The data is
stored in records. Each record contains data that pertains to a particular item, such as a
product or a customer. Every record in a repository has the same format or structure, which is
defined by the repository’s profile. The profile determines which attributes (data items) the
repository will store for each record, the data type of each attribute, and the order the
attributes are stored in the record. Each record in the repository has the same list of attributes,
but since not all attributes pertain to all records, a record may have unused (or empty) attribute
values.
For example, a business that sells movies would have a repository for storing information about
the movies they sell. Each record would store data about one movie. It would contain
attributes like the title of the movie, availability date, rating, director, cast, etc. Some of a
record’s attributes may be empty, for instance, if the availability date of a movie was unknown.

Enable 10 Basics
A Repository Opened in a Repository View
In this case, the repository is the database table; there is a record for each movie; the attributes
are the table’s columns – Title, Status, etc.; and the profile dictates which attributes are in the
table.
A Repository View is a display of the contents in a repository.
Enable supports several types of repositories. The feature that separates one type of
repository from another are the behaviors and actions allowed.
6.3 Profiles
Profiles are the heart of Enable. They define the nature of nature of stored data, its
relationship to other data, the actions allowed on that data, and who can access and perform
functions on that data.
6.3.1 Attributes
An attribute is a piece of data in the record that describes an item. For instance, if a repository
held contact information for a group of people, each record would describe one person and the
attributes would be Address, Phone, and Zip.
6.3.1.1 Data Types

Every record attribute has a data type. The data type specifies what type of data will be stored
in that field and how the attribute’s value should be interpreted. An attribute’s data type is
established when Enable is configured. Some data types have configurable characteristics. For
instance, if an attribute is declared as VARCHAR data type, the maximum length of the
attribute’s character string must also be specified.
When the editor displays an attribute value for the user to edit, the format it uses is defined by
the attribute’s data type, as is the format of the value the user will enter. For instance, an
attribute of the type DATE might display a calendar for the user to select from as well as a place

Enable 10 Basics
for the user to type the date in directly, whereas an attribute of the type CURRENCY may
display a value in the form of “$xxx.xx”.
When a user edits a record and saves it, the editor will assign validation errors to any attribute
values that do not match the attribute’s data type, such as characters entered into decimal
fields.
6.3.1.2 Primary Keys and Sequence Numbers

Each record in a repository has a unique record ID attribute called a key. The record’s unique,
identifying key is called its primary key. Primary keys are often auto-generated.
If the primary key is an auto-sequenced attribute field and Enable has been configured to allow
the user to set its value, if the user enters a value, it will be saved. If the user has not, Enable
will generate the field value based upon the next number in the sequence and any configured
rules. Once the new record is saved, the value of the auto-sequenced field is typically
configured so that it cannot be changed. Enable can be configured to generate unique
identifiers across a set of repositories, so no duplicate identifiers will be generated or saved.
If the record’s primary key is not auto-generated and the user does not enter a primary key, the
field will be left empty and an error for the record will be generated. If the user enters a value
in a primary key attribute that has been used elsewhere in the repository, a duplicate identifier
error for the record will be generated. Enable may also be configured to ensure that within a
set of repositories, no duplicate identifiers are generated or saved.
NOTE: A record’s primary key may be edited using the Inline Editor in a Repository View if
the user has sufficient permissions. This should not be considered common practice and great
care must be taken when modifying a primary key, as the key can be referenced in numerous
database tables and reports. Changing a primary key that is referenced by other repository
records will effectively break the link from those records, unless the same change is made to
those records as well.
A record’s primary key is not to be confused with its sequence number. A sequence number
only describes the order in which records are displayed in a Repository View, it is not used to
identify the record.
6.3.1.3 Code Sets

A code set is a special data type that consists of a list of predefined value pairs, “Code” and
“Description”, that contain all possible values for the attribute. When the attribute is displayed
for editing by the user, the user will be presented with the list of paired values to choose from.

Enable 10 Basics
If the Code and Description values are the same, only the Code will be displayed. If the Code
and Description are different, they will be displayed as “<Code Value> -- <Description Value>”.
Code Description
ARG Argentina
DEU Germany
IND India
USA USA
Select a Value for an Attribute with Datatype of Code Set

Enable 10 Basics
6.3.1.4 Editor Control Settings

Editor controls add additional specifications on how an attribute value is displayed and the
format the user will use to enter that value. These specifications are not determined by the
attribute’s data type, but by how the attribute value will be used. For instance, although an
attribute that holds a phone number might have the data type of VARCHAR and a length of 10,
an editor control rule for that attribute may denote that the editor will display the phone
number as “(xxx) xxx-xxxx” and that as the user types in digits, they will be composed in the
format.
6.3.1.5 Default Values

A record attribute may be configured to have a default value. When a new record is added, any
attribute that has a specified default value will be set to the default value. Depending on the
way the attribute was defined, the user or the system may be allowed to change the value.
6.3.1.6 Calculated Fields

A calculated field is an attribute whose value is determined by the values of other attributes or
system variables. For instance, the value of the attribute “Area of Rug” might be calculated by
multiplying the value of the attribute “Rug Length” by the value of the attribute “Rug Width”.
The values of calculated fields are not determined until the record is saved, both in the case of
a new record being added and when an existing record is being edited. If a user edits a value in
a calculated field, depending upon system configuration it may be overwritten with the system-
derived value when the record is saved.
6.3.1.7 Repository Sequences

Each record in a repository needs a unique ID to identify it. These IDs are tracked via a
sequence object (also called a sequence or sequence definition), which keeps track of the IDs
that have been used in that repository.
A sequence can be shared by multiple repositories, which would guarantee that each record
has a unique id across all the repositories using that sequence. A use for this would be if
products were being entered in multiple repositories but each product needed a unique
product ID. Although a sequence definition can be shared by multiple repositories, it is
recommended as best practice to create a separate sequence definition for each repository.
The default sequence object is commonly used if the user doesn’t care what the sequence
numbers are as long as they uniquely identify each record.

Enable 10 Basics
6.3.1.8 Auto-sequenced Fields

An auto-sequenced attribute field is similar to a calculated field. Upon the creation of a record,
Enable’s auto-generate sequence feature will automatically generate a unique value for the
auto-sequenced attribute field. Each repository profile may have one attribute that is defined
as auto-sequencing; typically this would be its primary key or an item number.
At the time of record creation, the user may be allowed to enter the value of an auto-
sequenced field (depending on the configuration of Enable). When the record is saved for the
first time, if the user is allowed to set a value for that field, its value will be saved. If not, Enable
will generate the field value based upon the next number in the sequence and any configured
rules. Once the new record is saved, unless Enable is configured differently, the value of the
auto-sequenced field cannot be changed.
6.3.1.9 Summary Attributes

When a record is opened in an editor, attributes selected as summary attributes are displayed
in the record header. Any attributes may be selected to be summary attributes, even attributes
in records that are linked to the repository.
6.3.1.10 Attribute Tabs and Groups

Records may have thousands of attributes, which can make them unwieldy to view or edit. For
display purposes, attributes are grouped, typically according to their function. For instance, all
the metric measurement attributes might be placed into a group called “Metric
Measurements” and the imperial measurements in a group called “Imperial Measurements”.
These attribute groups are then placed into larger groups called attribute tabs. The groups
Metric Measurements and Imperial Measurements might be placed into a tab named
“Specifications”.
When a record is opened in an editor, the attribute tabs are displayed. The tabs can be
expanded to show the attribute groups. The attribute groups can be expanded to show the
actual attributes themselves.
Each repository has its own set of attribute tabs and groups. Attribute tabs and groups are
defined and maintained by the system administrator.
6.3.1.11 Association Groups

An association group is a set of attributes that coordinate with each other, in that each
attribute field consists of a list of values, where the first value in the list of one attribute relates
to the first value in the list of the other attributes in the association group.

Enable 10 Basics
For example, the association group could have the attributes “Country”, “Tariff”, “Currency”,
and “Measurement”. The attribute values for a record might be:
Country = Argentina | Germany | India | United States
Tariff = 0.02 | 0.04 | 0.06 | 0.08
Currency = peso | euro | rupee | dollar
Measurement = metric | metric | metric | USCS
Where for the Country “Argentina”, the Tariff is “0.02”, Currency is “peso”, and the
Measurement system is “metric”.
Another way to visualize a record’s associated attributes would to envision the record having a
sub-table, such as shown below.
Country Tariff Currency Measurement
Argentina 2% peso metric
Germany 4% euro metric
India 6% rupee metric
United States 8% dollar USCS
Association groups can be used by more than one profile.
6.4 Snapshot Tables

Repository records are stored in XML. Accessing or manipulating attribute values requires
parsing the XML, which can be time-consuming. Snapshot tables are database tables that are
used to store attribute values that need to be accessed quickly. There can only be one
snapshot table per repository.
7 Saved Sets
A Saved Set is a group of one or more records in a repository. Each Saved Set has a unique
name and can be stored for later use. Saved Sets can be used to revisit the same group of
records without having to search for them again.
Saved Sets contain records from only one repository. A repository can have many Saved Sets.
For instance, a repository that contains products might have a Saved Set named “HugeMart

Enable 10 Basics
Products” that contains all the records whose company brand is “HugeMart ”. It might have
another Saved Set named “Cold Regions” that contains all the products sold in regions that
have cold winters. A snowshoe made by “HugeMart” and sold in Antarctica would be listed in
both Saved Sets. A jet ski made by “HugeMart” and sold in the tropics would only be listed in
the “HugeMart Products” Saved Set. A stove made by “TinyMart” and sold in the tropics would
be listed in neither Saved Set.
Saved Sets can also be shared so all other users can see and use them.
8 Taxonomies and Hierarchies

Businesses typically sell many different types of items and they need a way to organize their
product records so they can identify, store, and find them. They do that through the use of
taxonomies and hierarchies.
If a business sells party goods, they may sell balloons, tableware, and decorations. When they
think about their products, they probably think in terms of those categories: all the different
types of balloons are in the balloon category; all the silverware, tablecloths and paper plates
are in the tableware category; and all the streamers, banners and posters are in the decoration
category. Inside those categories, all the items have a similarity. There may be a lot of balloons
in different shapes, sizes and colors, but they are all balloons. The business may then divide
their products into more subcategories, such as dividing the balloons by the material they are
made of: mylar and latex. They can keep dividing their categories until they reach a point that
represents how they think of their products.
This type of categorization of data into categories and subcategories is called a tree structure.
Think of starting at the root (or trunk) of the tree – that’s the main category: Party Goods.
From the root, the data branches into subcategories: Balloons, Tableware, and Decorations.
Then Balloons splits into subcategories: Mylar and Latex. The point where a category splits is
called a node and so are the final subcategories (the ends of the branches). The actual products
themselves (the item records) are assigned to nodes. Every record is assigned to one, and only
one, node. Nodes can have multiple records assigned to them.
A taxonomy describes the path from the root to the node a product record is attached to.
Every product record has a taxonomy. Taxonomies are typically written as:
root.node.node…last_node (though they can be written in other formats, depending on the
configuration of Enable). For instance: Party Goods.Balloons.Mylar is the taxonomy for the
product record [balloon, #37, 10”, red, birthday]. For example:
Taxonomy Item Item Description
Party Goods.Balloons.Mylar #37 10”, red, mylar, birthday balloon.

Enable 10 Basics
Party Goods.Decorations.Banners #48 3’, paper birthday banner, in Spanish.
Party Goods.Tableware.Forks #95 Large silver serving fork.
Each product repository has one classification system that defines the repository’s taxonomy.
Each record appears only once in the taxonomy.
A hierarchy is similar to a taxonomy. Both are tree-like structures; however, a hierarchy
interacts with product records differently. A hierarchy captures a path that someone might
follow to find a product record.
Some items might logically be thought of as belonging in more than one category, so they can
appear in multiple places in a hierarchy. Returning to our party goods example, if a customer
wanted to buy paper plates for a birthday party, they might look in tableware, but they also
might look in decorations. Paper plates with birthday party designs could be thought of both as
tableware and as decorations. So a product item might be assigned to two different nodes and
have two different hierarchies. A package of 10”, purple paper plates might have the
hierarchies: Party Goods.Tableware.Paper Plates and Party Goods.Decorations.Paper Plates.
Hierarchy Item Item Description
Party Goods.Tableware.Paper Plates #37 10”, purple paper plates.
Party Goods.Decorations.Paper Plates #37 10”, purple paper plates.
A repository may have more than one hierarchy classification system. For instance, one
hierarchy might be used to prepare the Spring 2021 Catalog and another used for the Fall 2021
Catalog. Some items might appear in both hierarchies, while others may only appear in one.
A simple way to remember the difference between a repository’s taxonomy and its hierarchies
is: “A taxonomy is what the product is. A hierarchy is where someone might look for the
product.”
8.1 Types of Taxonomies and Hierarchies

Enable provides the ability to manage three distinct types of hierarchical relationships. The
main difference between them is how a record stores its taxonomy or hierarchy.
• Taxonomy – used to define what a record “is”. The taxonomy is stored in a designated
attribute in the record, for instance, an attribute called “Taxonomy”. (The attribute is
designated as a taxonomy by indicating in the profile that it is a Special Function attribute

Enable 10 Basics
and its code set is designated a taxonomy object.) Since there is only one attribute in a
record that stores the taxonomy, each record can be linked to only one node in the
taxonomy. A taxonomy node can also have category attributes associated with them. (See
Category Attributes). For example, a cup requires a field to capture its volume capacity, but
plate does not.
Taxonomy Behavior
• A repository can have only one

taxonomy.
• A repository record can be linked to only
one taxonomy node.
• A taxonomy can be assigned to multiple
repositories.
• Category attributes can be associated
with nodes.
• Hierarchy – A hierarchy is used to define a navigational path to one or more records.

The node assignments are stored in a separate repository, to allow each record to be
assigned to multiple hierarchy nodes. This allows the record to be found in more than
one category during a search. An example would be record for an “Abrasive Disk” item
that was assigned to a category node called “Abrasives” and a category node of “Power
Tool Accessories”. Records can be assigned to multiple nodes from multiple Hierarchies.
Hierarchies cannot have category attributes.
Hierarchy Behavior
• A repository can have multiple

hierarchies.
• A repository record can be linked to
multiple hierarchy nodes.
• A hierarchy can be assigned to multiple
repositories.
• Cannot have category attributes.

Enable 10 Basics
• Restricted Hierarchy – A restricted hierarchy is similar to a taxonomy. An attribute in the

repository is used to store a record’s hierarchy node assignment, so a record can only be
assigned to one node in the hierarchy. However, the record can be assigned to nodes in
multiple hierarchies. Each hierarchy’s node assignment is stored in its own repository
attribute. Restricted hierarchies cannot have category attributes.
Restricted Hierarchy Behavior
• A repository can have multiple

restricted hierarchies; each hierarchy
node assignment is stored in its own
attribute.
• A repository record can be linked to
only one node in a restricted hierarchy.
• Nodes cannot have category attributes.
All three types of classification listed above can be used to find records by drilling down the tree
structure and selecting a node to see the records assigned to that node.
8.2 Taxonomy and Hierarchies Paths

A taxonomy path or hierarchy path is the route traversed from the root node to get to the
assigned node. It is often called “a node’s taxonomy” or “a node’s hierarchy”. It is stored as a
string of characters. Enable offers three different notation methods for taxonomy paths or
hierarchy paths:
• Path codes: no path; relative path; and full path.
• If a relative or full path method is used, it must be further qualified by a choice of
delimited or fixed.
o The node names in a delimited path are separated by a designated delimiter
(such as a period).
o The node names in a fixed path are known by their position in the path.
Consider the following table and the relative conceptual diagrams pertaining to path codes:

Enable 10 Basics
Path Codes Hierarchy/Taxonomy Node Tree
No Path
1001
1001 = Tools
1002 = Hand Tools 1002 1003
1003 = Hammer 1004 1006
1005
Relative Path
TO1
TO1 = Tools
TO1.HT1. = Hand Tools HT1 PT1
TO1.HT1.HA1 = Hammer HA1 DR1
SD1
Full Path (Example: 3-levels)

TO1
TO1.0.0 = Tools
TO1.HT1.0 = Hand Tools
HT1 PT1
TO1.HT1.HA1 = Hammer HA1 DR1
HA2
9 Data Model Object Properties

Properties are metadata attached to a data model object, such as a default value for an
attribute. The Enable system defines properties for a data model object, such that all data
model objects of that type are created with the same set of system-defined properties.
Additionally, custom properties can be defined for some types of data model objects, such that
creating a custom property for a data model object does not add it to other data model objects.
Enable’s types of properties include:

Enable 10 Basics
• Repository attribute properties: The properties of the attributes in a repository. These

are managed at the repository level, so a repository’s attribute properties are distinct
and separate from another repository’s attribute properties, even if the repositories are
based on the same profile.
For example, two repositories, Eastern_Outlet and Western_Outlet, are based
on the same profile and have the attribute Contact. Editing the default value of
Eastern_Outlet’s Contact attribute will not affect the default value of
Western_Outlet’s Contact attribute.
• Repository Properties: The properties of a repository, such as whether a repository’s
valid records are automatically published. Repository properties are managed at the
repository level, so each repository’s properties are distinct and separate from the
properties of other repositories, even if they are based on the same profile.
For example, two repositories, Eastern_Outlet and Western_Outlet, are based
on the same profile and have the repository property Transmission_Option.
Editing the value of Eastern_Outlet’s Transmission_Option property will not
affect the value of Western_Outlet’s Transmission_Option property.
• Profile attribute properties: The attribute properties defined at the profile level. These
provide the initial values of the repository attribute properties when a new repository is
created based on that profile. When a repository is created, the values of its profile’s
attribute properties are copied into its repository attribute properties. Changing the
profile’s attribute properties does not change the repository attribute properties for any
existing repositories based on that profile.
• A taxonomy node property is metadata that applies to a taxonomy node. It describes a
characteristic of records assigned to that node. For instance, a property field might be
used to hold the name of the department responsible for records attached to the node,
or it might indicate if the records attached to the nodes are product records.
9.1.1 Properties Repositories

Two options exist to store the properties of a data model object:
• Properties Repository: (Preferred.) A repository that is created to hold the data model
object’s properties, then it is attached to the data model object. A properties repository
is more flexible and easier to access than directly-attached properties.
• Directly-attached Properties: (Non-preferred.) Properties are added directly to the
object definition. These are more ridged and harder to change and adapt over time
than properties repositories.
The benefits of creating a properties repository is that the properties can be managed,
imported and exported more easily, in the same manner that other repositories are rather than
the user having to edit the data model object.

Enable 10 Basics
10 Category/Dynamic Attributes
10.1 Category Specific Attributes/Category Attributes
Each record in a repository has the same structure – the same attributes, with the same data
types, in the same order. However, each record may not use all the attributes. If a business
sells multiple types of items, their product repository profile must include attributes for every
type of item. For instance, to store data about pens, the record would need to include
attributes relative to pens, such as the type of ink they use. But if the company also sold paper,
the record would also have to include attributes that describe paper, such as paper thickness.
Therefore, every record in the product repository must include attributes for both pens and
paper: type of ink and paper thickness. Records that contain data about pens would leave the
data fields for paper thickness empty. Records that contain data about paper would leave the
data field for type of ink empty.
Because a business can sell thousands of products, product records can have thousands of
attributes. While this is not a problem for computers, it can be a problem for computer users.
Most users don’t want to wade through thousands of empty attributes to find the ones they are
interested in. They only want to see the attributes that apply to the product record they are
accessing.
Enable can be configured to define these relevant attributes as category specific attributes (also
known as category attributes). Category attributes are assigned to a taxonomy node, which
means that Enable knows that all the records attached to that node use that attribute. The
taxonomy attribute is the control attribute for category attributes. Depending on system
configuration, descendent taxonomy nodes (a node’s subcategory nodes or children nodes) can
inherit category attributes as well. Note that category attribute values are not shared – each
record still maintains its own attribute value. The only effect of designating an attribute as a
category attribute is to indicate to Enable which attributes are relevant for a particular record.
Once category attributes have been defined and assigned to nodes in the taxonomy, and
product records have also been assigned to the taxonomy, viewing or editing a record in that
repository will only show the assigned category attributes.
WARNING: Be careful if you change the assignment of a category attribute to a node. Any time
a category attribute is unassigned from a node, the values of that attribute will be deleted in all
the records assigned to that node and in any children nodes that had inherited that attribute.
WARNING: Also be careful if you change the taxonomy assignment of a record. If the new
taxonomy node does not have the same category attributes as the old node, when the record is

Enable 10 Basics
reassigned, the values of the old taxonomy node’s category attributes will be deleted from the
record.
10.2 Dynamic Attributes

Dynamic attributes are like category attributes, but they can be assigned to a control attribute
that is not the taxonomy. The control attribute for category attributes is the taxonomy
attribute and only the taxonomy attribute, so a repository can only contain one set of category
attributes. Since dynamic attributes are assigned to other attributes, a repository can have
more than one set of dynamic attributes. If the control attribute for a set of dynamic attributes
is a hierarchy attribute, dynamic attribute values can be inherited.
10.3 Association Objects

An association object is used to assign category attributes to the taxonomy and to assign
dynamic attributes to a specific control attribute. It is a list of control attribute values and their
assigned category/dynamic attributes. There is one [control-attribute-value |
category/dynamic-attribute] pair for each attribute assigned to a control attribute. In the case
of category attributes (which are controlled by the taxonomy) and dynamic attributes that are
controlled by a hierarchy attribute, the association object also indicates if an attribute for a
node can be inherited by its children nodes, meaning that the attribute is assigned once to the
parent node but also applies to all its children nodes.
If a code set is assigned to a category/dynamic attribute, the associations for the attribute can
also specify a subset of the code set values. An example would be a category attribute named
“Color” that is assigned to a code set containing the values: “Blue”, “Black”, “Red”, “Green”,
and “Yellow”. An assignment of the Color attribute to the node: “Stationary.Writing
Materials.Pens” may limit the values for Color to “Blue”, “Black”, or “Red” while the assignment
to the node: “Equipment.AudioVisual.Laser Pointers” may limit the values for Color to “Red” or
“Green”. When a user is editing a record, the dropdown list for Color will only show the
designated subset of values.
11 Link Relationships
11.1 Linked Records
Linked records are records that have a relationship with another record. For example, a
product record may contain links to accessory products or related products. The records can be
in the same repository or in different repositories. Link relationships can be “one-to-one” (one
record linked to another record), “one-to-many” (one record linked to more than one record),
or “many-to-many” (records can both have more than one record link to them and can link to
more than one record).

Enable 10 Basics
Records can be linked to digital asset metadata records. A digital asset is a file, such as an
image, spreadsheet or PDF file. For every digital asset, Enable’s DAM keeps a metadata file in
the DamMaster repository. (See Digital Asset Management (DAM) for more information.) If a
record is linked to a digital asset metadata record, it is said to be linked to the digital asset.
11.2 Linked Repositories

Repositories can also be linked and have link relationships. The path of these multiple link
relationship between repositories is used to control publication, customized import, customized
exports and can be used for other purposes as well.
In a link relationship, one repository is the parent and other repository is the child. The linkage
between repositories is created by joining one or more attributes from both repositories. The
join attributes must be defined as part of the snapshot table in order to participate in the join.
Once a link has been established, the link is available to be displayed as a link table in both
parent and child repositories.
12 Search Filters
Filters provide a way for the user to quickly find a set of records based on the values of selected
attributes.
During configuration, the system administrator can select specific attributes in a repository to
be drill-down indexes.
When the user opens the Filter Sidebar, a list of the drill-down index attributes appear. Upon
the user expanding an index attribute, a list of all the values that attribute has in the repository
is displayed. Each attribute value displays a count of how many times that attribute value
appears in the repository.
Selecting an attribute value causes a filter to be placed on the Repository View so that it only
lists those records that contain the specified attribute value. It also causes an Active Filter box
to be displayed in the Active Filters Bar that indicates the name of the attribute and what filter
is being applied to its values.
If a saved set is in use in the Repository View, the filter will show attribute values and counts
applicable to the saved set only.
If additional attribute value filters are selected (from the same attribute or from different
attributes) their effect is such that any record that contains at least one of the indicated
attributes’ values will be included in the Repository View record list.

Enable 10 Basics
13 Record Validation
The attribute values of a record are validated when attribute values are entered into the
system. This typically occurs when a record is imported into the database, or when the user
creates a new record or opens an existing record in the Detail Editor, edits and saves it.
Attribute values are checked against constraints placed by the data type, editor control
settings, and explicit validation rules. The constraints are independent of validation levels (i.e.,
they are always applied). Validation rules can be assigned to specific validation levels.
Different syndication targets may have different requirements for data content, such as which
attribute values are required and whether or not they accept attribute values flagged with
warnings.
The use of validation levels gives an organization the ability to determine if particular validation
errors and warnings are severe enough to prohibit the syndication of a record to a particular
target. They allow a record to be deemed good enough for syndication to one target but not
another.
Validation levels are associated with the quality of the record’s attribute values. Validation
rules are assigned to validation levels; for a record to reach a level of validation, it must pass
the validation checks for that level and all the validation levels beneath it.
Enable supports up to five levels of validation and they are often labeled “A” through “E”, such
that in order for a record to be deemed valid at level A, it must satisfy all the requirement levels
for E, D, C, and B as well.
Records are eligible for promotion to Production once they pass the validation rules for their
assigned validation level. Once promoted, they will only be available for syndication to those
targets which they are ready for (have achieved a validation level high enough for). Note that
since validation levels are cumulative, records that are available for syndication to one target
will also be available for syndication to all targets that have the same or lesser validation level
requirements.
A record’s validation status indicates whether it achieves its assigned validation level. The
possible status values are:
• Green: Promotable.
• Yellow: Has warnings – May be promotable according to system configuration and user
entry.
• Red: Has severe errors – Unpromotable.
• Black: Record not yet validated.
During system configuration, it is determined which validation rules map to which validation
levels and whether the promotion of records allows for errors or warnings.
For detailed information about how a record’s validation status is determined, see the Enable
10 PIM Administration Guide.

Enable 10 Basics
13.1 Record Validation Example

The following diagram illustrates how validation rules assigned to validation levels affect the
validation status of records for those levels:
Validation Rules (By Levell) Example Item Records Level Status
SKU Group required for Level A

Master Item Id = 1234 Level B
Level A
Long Item Description = Level C
SKU Group =
Taxonomy = Level D
Long Item Description
required for Level B Level E
Level A
Taxonomy required for Master Item Id = 1235 Level B
Level C Long Item Description = My Item
Level C
SKU Group =
Taxonomy = Wheel Brushes Level D
Level E
Level A
Master Item Id = 1236 Level B
Long Item Description = My Item
Level C
SKU Group = Steel Brushes
Taxonomy = Wheel Brushes Level D
Level E
In the above example, if the first record (with Master Item Id = 1234) has a required validation
level of D or E, the record will be deemed valid. But if it must reach level A, B, or C to be
promotable, it would be deemed not promotable and flagged with at least one severe error.
The second record is valid if its required validation level is set to any level but A.
The third record is deemed valid regardless of what its required validation level because all
validation rules have been satisfied.
14 Staging and Production

In order to insulate “production-ready” data from updates that may be incomplete or invalid,
Enable supports the creation of separate Staging and Production versions of the data. Records
are stored in the Staging and Production repositories depending on their readiness for use.
The Staging repository holds records that are in the process of being populated or validated.
Staging is thought of as a work area.
The Production repository holds records that are ready for use: they have been validated and
are available for internal use or export.

Enable 10 Basics
Some organizations also have a temporary Pre-staging repository for records that are not yet
ready for Staging. Pre-staging is typically used for imported data that needs processing or
validation before it is ready for Staging.
After a record in a Staging repository has been deemed valid (see Record Validation), it is
copied to the Production repository, where it overwrites any previous copy of the record. This
act is called promotion. Enable can be configured to automatically promote records when they
are valid for the next repository or the system can be configured to require promotion to be
triggered by a process or user. When records are promoted, they are not deleted from Staging.
Data that is added or updated in repositories not configured for Staging-Production will be
“production-ready” when the records are saved.
15 Promotion and Package Promotion

Records are modified in the Staging environment and then moved to Production using the
promotion process. Promotion can be handled automatically or manually, depending on
system configuration.
A package is a group of records from linked repositories. If a repository is designated as
package-dependent, none of its records will be promoted to Production if any of the records in
the package have severe validation errors. If a repository is not designated as package-
dependent, its valid records will be promoted to Production even if the packages containing
them are deemed invalid.
The package promotion process has several steps:
1. Creation of temporary saved sets for each repository in the package.

Enable 10 Basics
2. Validation of the records in the temporary saved sets for each repository.
3. Revision of the temporary saved sets based on package promotion rules (for example,
remove any records belonging to packages that have validation errors).
4. Promotion of the records in the temporary saved sets for each repository.
5. Removal of the temporary saved sets (to reduce clutter).
The validation and promotion operations are visible in the Job Monitor as individual jobs. The
Scheduled Import Jobs shows the overall package promotion progress.
15.1 Package Promotion in Detail

The example below shows the use of a package defined from the root of SKU Group. Item
records are linked to the SKU Group record. Brand, Manufacturer and Item Business Unit
records are linked to each Item record. The SKU Group, Item, and Item Business Unit records
are designated as Package-Dependent. This means that if any records within the package have
a severe validation error, the Package-Dependent records will NOT be promoted to Production.
The Brand and Manufacturer records are not designated as Package-Dependent, so they will be
promoted to Production even if records in the Package are deemed invalid.
SKU Group - XYZ
Item - A Item - B Item - C
Brand Manufacturer Brand Manufacturer Brand Manufacturer
Item Item Item

Item - Item - Item -
Business Business Business
Lagasse Lagasse Lagasse
Unit - ORS Unit - ORS Unit - ORS
The Package Promotion capability supports the ability to promote sibling non-root records
independently. In the example above, Item A, Item B, and Item C are sibling records because
they belong to the same SKU Group XYZ. If Package Promotion is launched on the Item records
instead of on the SKU Group record, the promotion of Item A is possible even if Item B or Item
C are invalid. This assumes that SKU Group XYZ is valid and that Package-Dependent children of
Item A are also valid.

Enable 10 Basics
Below are possible scenarios in which Package Promotion is invoked for Item A. Checkmarks
indicate valid records; an ‘X’ marks invalid records.

Enable 10 Basics
If the Enable implementation utilizes validation levels (see Record Validation) to control the
quality of the data made available for Syndication and Publication, the Package Promotion
processing uses the validation level settings of the records being promoted to determine which
validation rules to apply. Only applicable validation errors are included in the Package
Promotion report. If validation errors are found, correction files will be generated that list the
records containing the errors. If many validation errors are found, a log update file will also be
generated. These files will be included in the same ZIP file as the Package Promotion report.
Validation levels for records can be set manually. The Package Promotion capability also
provides a mechanism for automatically setting the validation level of all the records in the
package to a designated minimum level (depending on the Package Promotion configuration
settings). The automatic setting of the validation level will only raise the validation level on
qualifying records – it will not lower the level. For example, if three of the five items in the
package promotion are currently set to validation level C and the other two are set to level A,
initiating the package promotion with a validation level of B will only raise the three records
from C to B. The other two records will remain at level A.
15.2 Package Promotion Report

Each time the Package Promotion function is invoked, a report is generated that details the
steps taken during the Package Promotion processing.

Enable 10 Basics
The first section of the report displays the details of the promotion package being used.
Package: SKU Group has 3 levels:
PIM_Product_Staging
PIM_Item_Staging
PIM_Brand_Staging
PIM_ItemBusinessUnit_Staging
PIM_Manufacturer_Staging
PIM_ProductLine_Staging
The next section provides details on the saved sets that are generated for each repository
comprising the Promotion Package. The repository the Package Promotion process was
launched on is listed first.
Creating saved set Package PIM_ItemBusinessUnit_Staging_1436463369505 and adding 325 records .

Successfully created and populated saved set.
Repository PIM_ItemBusinessUnit_Staging not root-level. Identifying packages from selected
items.
Create Saved Sets for Packages:
[Package PIM_Product_Staging_1436463369505]
Adding 36 records.
[Package PIM_Item_Staging_1436463369505]
Adding 325 records.
[Package PIM_ProductLine_Staging_1436463369505]
No records added to saved set.
[Package PIM_ItemBusinessUnit_Staging_1436463369505]
Adding 325 records.
[Package PIM_Brand_Staging_1436463369505]
Adding 9 records.
[Package PIM_Manufacturer_Staging_1436463369505]
Adding 9 records.
The next section provides details on the validation of the records in each repository included in
the saved sets previously generated. For environments that have multiple validation levels
defined, only the validation errors that are applicable for the current level are displayed.
Validate Saved Sets for Packages:
Saved Set: [Package PIM_Manufacturer_Staging_1436463369505]

Performing validation.
Validation job completed successfully.
Validation processed 9 finding 0 errors.
Saved Set: [Package PIM_Brand_Staging_1436463369505]

Saved Set: [Package PIM_ItemBusinessUnit_Staging_1436463369505]

Validation processed 325 finding 0 errors
Saved Set: [Package PIM_ProductLine_Staging_1436463369505]

Enable 10 Basics
Saved Set: [Package PIM_Item_Staging_1436463369505]

Validation processed 325 finding 2 errors:
ERROR: Master Item Id[1002] (Item Validation Level: C) has a critical error
SKU Group Auto-Id: :Failed Level C rule "Required for Level C" :data is empty
Master Item Id: 1002 :Failed Level C rule "Linked Main Image" :Expected one or
more linked records in: DAMLink - found none.
ERROR: Master Item Id[1003] (Item Validation Level: A) has a critical error
UPC: :Failed Level A rule "Required - for Level A" :data is empty
UNSPSC UN Product Class Code: :Failed Level A rule "Required - for Level A" :data
is empty
SKU Group Auto-Id: :Failed Level C rule "Required for Level C" :data is empty
Master Item Id: 1003 :Failed Level C rule "Linked Main Image" :Expected one or
more linked records in: DAMLink - found none.
Saved Set: [Package PIM_Product_Staging_1436463369505]

Validation processed 36 finding 1 errors:
ERROR: SKU Group Auto-ID[1234] (Item Validation Level: A) has a critical error
SKU Group: :Failed Level A rule "Required - for Level A" :data is empty
The next section provides details on any alterations made to the saved sets based on the results
of validation. Records are removed that have a validation error or that belong to a Package-
Dependent repository that cannot be promoted because one or more records in the package
have a validation error.
Update Saved Sets Based on Validation errors
Saved Set: [Package PIM_Product_Staging_1436463369505]
Validation Errors:
SKU Group Auto-ID[1234]
Parent Validation Errors:
No changes
Child Validation Errors:
No Changes
Saved Set: [Package PIM_Manufacturer_Staging_1436463369505]
Validation Errors:
No Changes
Parent Validation Errors
No Changes
Child Validation Errors
No Changes
Saved Set: [Package PIM_Brand_Staging_1436463369505]
Validation Errors:
No Changes
No Changes
No Changes
Saved Set: [Package PIM_ProductLine_Staging_1436463369505]

Validation Errors:
No Changes

Enable 10 Basics
No Changes
No Changes
Saved Set: [Package PIM_Item_Staging_1436463369505]
Validation Errors:
Master Item Id[1002]
No Changes
Saved Set: [Package PIM_ItemBusinessUnit_Staging_1436463369505]

Validation Errors:
No Changes
Master Item Id[1002]; Business Unit [ORS]
No Changes
The next section of the report details the results of the promotion process for the repositories
of the records remaining in the corresponding saved set. It is expected that all remaining
records will be promoted successfully.
Promote Saved Sets in Packages
Promote Saved Set: Package PIM_Manufacturer_Staging_1436463369505 in repository:

PIM_Manufacturer_Staging
Promotion Completed Successfully. Records Processed: 9 Records with errors: null
Saved set promoted successfully.
Promote Saved Set: Package PIM_Brand_Staging_1436463369505 in repository:
PIM_Brand_Staging
Promote Saved Set: Package PIM_ItemBusinessUnit_Staging_1436463369505 in repository:
PIM_ItemBusinessUnit_Staging
Promotion Completed Successfully. Records Processed: 322 Records with errors:
null
Promote Saved Set: Package PIM_ProductLine_Staging_1436463369505 in repository:
PIM_ProductLine_Staging
Promote Saved Set: Package PIM_Item_Staging_1436463369505 in repository: PIM_Item_Staging
null
Promote Saved Set: Package PIM_Product_Staging_1436463369505 in repository:
PIM_Product_Staging
null
The final entry in the report provides the elapsed time for the Package Promotion process from
start to finish.

Enable 10 Basics
End of Package Promotion process. Processing time: 0 hours, 9 minutes.
If validation errors are found, correction files will be generated containing the records with
errors. If many validation errors are found, a log update file will also be generated. These files
will be included in the same ZIP file as the Package Promotion report.
16 Syndication
Syndication is the process of exporting Production data to a particular target, (user of the data).
Syndication targets may include targets such as web pages, servers that process product orders,
or subsidiary businesses. A syndication channel is a data stream consisting of a set of data
being transmitted (or made available to) a particular syndication target.
An organization may have different validation requirements for different syndication targets.
For example, the server that processes orders may have minimal requirements, while the
website requires that each item includes more data, such as marketing data and images.
The use of validation levels allows an organization to specify that a record is valid for one
syndication target but not valid for another. Validation requirements are cumulative as levels
are ascended, meaning that records that pass a validation level must have passed lower
validation levels as well. See Record Validation for more information regarding validation levels
and the process of record validation.
Records are eligible for promotion to Production once they have reached their assigned
validation level. Once promoted, they will only be available for syndication to those targets
which they are ready for (have achieved a validation level high enough for). Note that since
validation levels are cumulative, records that are available for syndication to one target will also
be available for syndication to all targets that have the same or lesser validation level
requirements.
For example, an organization might name their lowest validation level (the level with least
requirements) “Mainframe”, indicating that records that pass the Mainframe level of validation
are ready to be syndicated to the mainframe that processes product orders. The organization
may also define a higher validation level named “Web” that requires a record not only to pass
Mainframe validation, but also to contain other specified, validated data before it is available
for syndication to the web.
Records assigned to the Mainframe level will be eligible for promotion to Production as long as
their data quality is sufficient to achieve the Mainframe validation level. The records will not be
available for syndication to the web unless they are assigned to Web Level and also pass Web
level validation. Note that in order for a record to pass Web level validation, it must also have
passed Mainframe validation, thus they would be eligible for syndication to both targets.

Enable 10 Basics
16.1 Transmission Options

A transmission option is an object that defines the method of transmitting an exported file to a
destination. A transmission option can be used by more than repository. A transmission option
object maintains a different set of configuration settings depending on the type of transmission
option. Transmission options store information such as the protocol used, modifications to the
resulting file name, destination, and any necessary destination-imposed user authentication.
17 Channel Readiness
A syndication channel is a data stream consisting of a set of data being transmitted (or made
available to) a particular syndication target.
Channel readiness is a measure of how ready a channel is to be syndicated to its target, that is
to say, how many of the required record attribute values have reached a validation level
sufficient to be syndicated to their target.
18 Digital Asset Management (DAM)

An organization’s digital assets may include digital images, audio files, video files, PDF
documents, Microsoft Office documents, and other file types.
The DAM is the set of folders, repositories, and processes used to store digital assets and make
them accessible to the rest of Enable.
The records in the DamMaster repository hold the metadata for the digital assets. Each digital
asset has one record in DamMaster. The metadata includes values such as the asset’s id, file
name, and media type.
Digital assets can be associated with any repository record, depending on system configuration.
The records in the DamLink repository hold the associations between the DamMaster records
and records in the repositories that have been configured to allow digital assets to be linked.
19 Templates
The Template functions allow users to define and save configurations for the import, export,
syndication, exchange, and publication of Enable repository data. Templates may be used in
both scheduled and manually triggered activities.

Enable 10 Basics
20 Workflow
The Workflow capability allows multiple users to manage a particular job through a defined
process determined by the requirements of the organization.
A workflow is a business process. It is a set of tasks that must be performed to fulfill a function.
A work item is a marker for a specific job that is going through the process. The work item
contains information about the job and where the job is in the process.
For example, a business may have the following workflow for bringing a new product to market:
Someone comes up with the idea to start selling a new product. They create a proposal
and start distributing it to different departments to get input on the idea. Sales writes
up their assessment of the marketability of the product and gathers some data. They
attach it to the proposal and send it on. Engineering and Procurement each provide
assessments and gather data, attach it to the proposal and send it on. The proposal’s
owner may decide the Product Safety department needs to be consulted before the
proposal is sent to management for approval, or they may decide Product Safety’s
involvement is not necessary and send the proposal straight to management.
Management then makes the decision to accept the proposal, reject it, or to send the
proposal back through the process with a request for more information.
The workflow in this example is the process the company follows to make the decision whether
or not to sell a new product. The proposal serves as the work item. It identifies the proposed
product, acts as a collection point for data gathered about the product, and its signature list
indicates where the proposed product is in the workflow.
Work items are implemented in Enable as one or more records (or a Saved Set of records) that
are put into a preconfigured workflow.
For a work item to advance in a workflow, tasks need to be performed by one or more users or
groups of users (participants). These tasks may involve the use of automated processes, such
as retrieving information from an FTP server or other external system, generating and
transmitting files, sending e-mails, updating data in Enable, etc.
Depending on a workflow’s configuration, when a user acts on a work item, they may have only
one action to perform, more than one action to perform, or a choice between actions to
perform.
There may be only one route a work item can take through a workflow, with the work item
being passed sequentially from one participant to the next. Or the route may split with
versions of the work item sent as new work items to multiple participants concurrently. Routes
that have split may merge back into one route further along the workflow or they may stay
separate for the rest of the workflow.
There are four ways work item records can be sent into a workflow.
1. One record is sent into a workflow as one work item.
2. A Saved Set of records is sent into a workflow as one work item.

Enable 10 Basics
3. Multiple records are sent into a workflow as one work item.

4. Multiple records are sent into a workflow as multiple work items.
The method a workflow uses to process submitted records is determined by the way it was
configured by the system administrator.
Depending on system configuration, a record can be in more than one workflow at a time.
Additional records cannot be added to a multi-record work item once it has been created.
A work item cannot move forward to the next activity task of a workflow process until all its
associated records have been processed at the current activity task.
Workflows may be configured to lock records against editing while they are in a work item. If
they are, the records cannot be edited until the work item is completed except by the user(s)
who are currently assigned to the work item. If the record is part of a multi-record work item,
all records in the work item must be completed before the records are unlocked.
21 Job Scheduling
Job scheduling is the function that allows pre-scheduling one-time or repeated activities:
• Imports
• Exports
• Promotions
Each of the three types of scheduled activities has its own set of repositories and workflows:
• A workflow that triggers a scheduled activity to occur.
• A scheduling repository that stores the configuration details for each instance of an
activity; one record per each defined activity. Configuration details might include which
template to use, transmission options, how often to perform the activity, etc.
For instance, there might be an export of the Product IDs from the product repository to
a particular target scheduled to run every Tuesday night. There would be a record in the
Scheduled Exports repository that would include the name of the export template, the
name of the repository, how often the export should run, etc.
• A scheduled jobs repository that contains records representing the currently active or
recently completed jobs. Whenever a job is initiated, the details for that job are copied
to the scheduled jobs repository. This record is subsequently updated to reflect the
current status of the job.
To continue the example, every Tuesday night, the workflow would kick off the export
of the Product IDs, and it would store the details about the export in the Scheduled
Exports Jobs repository, including the status of the job – is it completed, were there
errors, etc.

Enable 10 Basics
22 Events
The Events function allows the user to specify changes to a set of records that will occur at a
later date and time. Optionally, the user may specify an expiration date for the changes, after
which the records will revert to their state before the Event was defined.
23 Security
23.1 User and Group Security
User groups in Enable are defined based on types of system responsibilities, such as
Administrator, Product Manager, Publications Manager, or Syndication Manager. These groups
are designed around each organization’s specific business processes. To efficiently manage the
Enable users’ security, EnterWorks recommends that system security is managed at the user
group level.
Enable user groups control both which functional areas of the application a user is allowed to
view or perform, and what level of access a user group’s members have to objects within
Enable PIM (e.g. code sets, users, groups, repositories, etc.). Each type of object can be set to
assign a user group’s members permission to create, read, edit or delete existing Enable PIM
data model objects.
Repositories have additional permission to allow adding, editing, sync-in (importing), and
deleting records
23.2 Attribute and Record Security Filters

Attribute security filters and record security filters determine which of a repository’s attributes
and records may be read or edited. Defining security for a repository consists of granting
access permissions to user groups for the records and attributes the security filters have made
available for reading and editing.
Attribute security filters list which attributes are available to be read or edited. If a repository’s
security settings do not specify an attribute security filter, the default filter will be used and no
attributes will be visible – no users will be able to see any data in that repository.
Record security filters return only the records that match their search conditions. The use of
record security filters is optional. If a record security filter is not applied, the default record
security filter returns all records.
Repository security consists of defining: for the set of records the record security filter returns,
and the attributes made visible by an attribute security filter, what access permissions are
assigned particular user groups.

Enable 10 Basics
Security for profiles, code sets, hierarchies, and taxonomies does not use attribute and record
security filters. User groups are directly assigned permissions.

Enable 10 Basics

Uploaded by

Copyright:

Available Formats

You might also like

Enable 10 Basics

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Enable 10 Basics

Uploaded by

Copyright:

Available Formats

Enable 10 Basics

• Enable 10.0 Release Enable Suite:

EnterWorks®, Acquisition Inc. a Winshuttle Company

Page 1 of 39 Revised 08/02/2019

©EnterWorks Acquisition, Inc.

1.888.242.8356 (Sales and General Information)

EnterWorks ® Enable 10 Basics

Oracle is a registered trademark and Oracle 10g is a trademark of Oracle Corporation.

Page 2 of 39 Revised 08/02/2019

Page 3 of 39 Revised 08/02/2019

15 Promotion and Package Promotion .................................................................................. 27

Page 4 of 39 Revised 08/02/2019

pathnames Pathnames are shown with backslashes, as for Windows systems.

If italicized and in angle brackets (< >), it denotes a variable.

Page 5 of 39 Revised 08/02/2019

How to reach us Comments

On the Web: For detailed discussions of hardware, software,

Page 6 of 39 Revised 08/02/2019

5 Users and Groups

Page 7 of 39 Revised 08/02/2019

5.1 User Password Management

5.2 Impersonate User

Page 8 of 39 Revised 08/02/2019

6.2 Repositories and Records

Page 9 of 39 Revised 08/02/2019

A Repository Opened in a Repository View

6.3.1.1 Data Types

Page 10 of 39 Revised 08/02/2019

6.3.1.2 Primary Keys and Sequence Numbers

6.3.1.3 Code Sets

Page 11 of 39 Revised 08/02/2019

Select a Value for an Attribute with Datatype of Code Set

Page 12 of 39 Revised 08/02/2019

6.3.1.4 Editor Control Settings

6.3.1.5 Default Values

6.3.1.6 Calculated Fields

6.3.1.7 Repository Sequences

Page 13 of 39 Revised 08/02/2019

6.3.1.8 Auto-sequenced Fields

6.3.1.9 Summary Attributes

6.3.1.10 Attribute Tabs and Groups

6.3.1.11 Association Groups

Page 14 of 39 Revised 08/02/2019

Country Tariff Currency Measurement

Argentina 2% peso metric

Germany 4% euro metric

India 6% rupee metric

United States 8% dollar USCS

Association groups can be used by more than one profile.

6.4 Snapshot Tables

Page 15 of 39 Revised 08/02/2019

8 Taxonomies and Hierarchies

Taxonomy Item Item Description

Party Goods.Balloons.Mylar #37 10”, red, mylar, birthday balloon.

Page 16 of 39 Revised 08/02/2019

Party Goods.Decorations.Banners #48 3’, paper birthday banner, in Spanish.

Party Goods.Tableware.Forks #95 Large silver serving fork.

Hierarchy Item Item Description

Party Goods.Tableware.Paper Plates #37 10”, purple paper plates.