Universe Builder
Use the Universe Builder to design universes.
What Are Universes?
An installation of Syntelate XA can support multiple universes. The concept of universes makes it possible to separate data within a single installation of Syntelate XA.
Designer elements in one universe cannot be accessed from another universe. For example, with reference to the above diagram, you could not add scripts or data entry elements in the Personal Travel universe to a desktop in the Business Travel universe.
Whenever you create a new Designer element, such as a desktop, script, or workzone, you must specify the universe to which it should be added.
Note: Non-Designer elements — such as agents, intervals, and completion codes — are not associated with a particular universe and so can be shared across universes.
Data Sources, Objects, and Links
When you build a universe in the Universe Builder, you can add data sources, data source objects, and data source object links. By doing this, you’re defining from where Syntelate XA can read data, and to where it can write data, in this universe.
Data Sources
A data source could be a database or an external CRM, for example. Every universe automatically has the Syntelate XA database configured as one data source, but you can add additional data sources.
Data Source Objects
A data source object is an object in a data source, such as a particular database table. For example, you may choose to store your customers’ details in a table called CONTACT_X in your Syntelate XA database. If so, you would want to have this as a data source object in your universe. In the Data Entry Designer, you would then be able to create data entry elements that access this database table and its fields.
From the Universe Builder, you can create new tables in the Syntelate XA database to use as data source objects. You can also add new fields to existing tables in this database.
Data Source Object Links
A data source object link specifies the relationship between two data source objects. For example, where used, CONTACT_X would usually be linked to INTERACTION_X as follows:
| Parent object name | Child object name | Parent field | Child field |
|---|---|---|---|
| CONTACT_X | INTERACTION_X | CONTACT_ID | CONTACTNUM |
CONTACT_X is the parent object, since there is a one-to-many relationship between CONTACT_X and INTERACTION_X: for a single customer in CONTACT_X, there can be many interactions in INTERACTION_X.
The CONTACTNUM field in INTERACTION_X references the CONTACT_ID field in CONTACT_X (the primary key). This is how each interaction record in INTERACTION_X is associated with a customer record in CONTACT_X.
Tasks
Click a task for step-by-step instructions: