Getting Started

About Central

Central is a next-generation automation platform that pairs a low/no-code integration engine with a data quality management solution to synchronize data across multiple systems. It addresses complex data synchronization and workflow needs across eCommerce, ERP, CRM, HRIS, Purchasing, and Supply Chain systems — with minimal coding required.

Central covers the full software development lifecycle: design, build, test, version control, deployment, monitoring, and maintenance. It also emphasizes data quality, metadata management, relationship mapping, and data architecture governance.

Purpose of This Guide

This guide assists users and developers in building and customizing your company's integration platform. It assumes the reader has a technical understanding of database structure, data terminology, your business solutions, and data inputs and downstream consequences.

For questions or support, contact support@teamcentral.ai.

Getting Started Checklist

Ensure you have the following before beginning to build your model:

• Central software URL
• Central Admin access
• Working knowledge of the software systems you plan to integrate
• Technical documentation for each connecting software system, including the authentication information

Key Definitions

Term	Definition
Common Model	The starting point for defining common entities within your business (e.g. Customer, Vendor, Employee, Sales Order). All publishing and subscribing flows through the Common Model.
Data Model	Your customized copy of the Common Model, defining the data you need to flow between systems. It consists of common fields and unique, personalized Schema Definitions.
Data Model Property	The actual data points that flow between systems (e.g. a Customer Data Model may include name, address, and email).
Connector	Connectivity to any data source (e.g. SaaS, API, Internal Customer API, Database, File Store).
Endpoint	A specific instance of a Connector for the type of data you want to connect to (e.g. Salesforce Account Data).
Endpoint Action	A specific set of instructions on how the Endpoint performs tasks such as reading, writing, and deleting data.
Publisher	An Endpoint that triggers data to be integrated.
Subscriber	An Endpoint that receives data to be integrated.
Data Hub	A logical grouping of Endpoints that make up a single data synchronization solution.
Agent	At the center of all transactions, an Agent is constantly pushing data out and receiving data in.

Conventions Used in This Guide

Throughout this guide, you will encounter the following callout types:

NOTE

Useful information or a helpful tip regarding the current topic.

NOTE

Critical information regarding the current topic.

Advanced Tool

Descriptions of advanced features within the software, intended for those with developer knowledge and skills.

Advanced Configuration

Specific implementation examples of advanced features, intended to give developers a broader view of atypical applications.

Example

Analogies and/or examples for added illustration and understanding.

Best Practice

Recommendations on software setup and maintenance.

UI Icon Reference

Throughout the application, icons appear on endpoint cards, action trees, and status indicators. Here is a reference for what each icon means.

Endpoint Card Icons

Icon	Meaning
	Interval Scheduler — This endpoint runs on a timed interval
	Day of Week / Month Scheduler — This endpoint runs on a weekly or monthly schedule
	On Demand — This endpoint can be triggered manually (click to run)
	Key Replication — This endpoint has key replication actions configured
	Connector Not Found — The connector associated with this endpoint is missing

Action Tree Icons

Icon	Meaning
	API Read Action — Reads data from an API endpoint
	API Save Action — Writes data to an API endpoint
	API Delete Action — Deletes data via an API endpoint
	SQL Read Action — Reads data from a SQL database
	SQL Save Action — Writes data to a SQL database
	File Read Action — Reads data from a file source
	File Save Action — Writes data to a file destination
	Get Session Values — Extracts values from a prior API response for use in subsequent actions
	Obtain Primary Key — Scrapes and indexes the primary key from a save response

Status Indicators

Icon	Meaning
	Record Exists — Entity found in the index
	Record Not Found — Entity not in the index
Draft	Draft — Work-in-progress configuration version
Live	Live — Currently deployed production version

The Process

Upon logging into Central for the first time, you'll follow a six-step process to set up your integrations:

1. Build Data Models — Define Schemas (data values) and assign Schema Properties that describe the data you want to flow between systems.
2. Configure Connectors — Identify and configure the applications and systems that store your Data Models, providing API credentials for each.
3. Build Data Hubs — Organize how data flows between systems by creating logical groupings of Endpoints, assigning publish/subscribe actions, and mapping data.
4. Use Templates — Where available, leverage pre-configured Templates that tie specific Data Models to configured Endpoints with basic mapping already in place.
5. Deploy — Push your configuration to a Live version. Data Hubs have internal versioning: Draft (work-in-progress), Live (production), and Previous Deploy (historical copies).
6. Monitor — Track integration health via the Dashboard, investigate individual messages and errors, and set up Alerts for error notifications.

Organizing Your Data

Before building, organize the data you'd like to connect between systems:

1. Document the data within each system that you want to connect
2. For each entity (e.g. Customer), list all fields you want to include (Name, Address, City, State, etc.)
3. Cross-reference corresponding fields across all systems you plan to connect
4. Any field you plan to read or write should be documented — each becomes a Schema Property

Example

If your source of truth for Customer data is Salesforce, document all Customer fields you want to include (Name, Address, City, State, Zip Code, Phone Number, etc.). Then go to each connecting system and document the corresponding fields. You'll end up with a cross-reference of all Customer data across systems.

Build Data Models

Data Models are customized, logical groups of data you are sharing between systems. Each Data Model is comprised of Schema Definitions — custom categories for the data you want to flow between systems (e.g. Contact Person).

Within a Schema Definition, you assign Schema Properties that detail the data for that definition. There are three types:

• Simple Properties — Single value-to-value properties representing common, static data (e.g. customer name)
• Foreign Key Properties — Cross-referenced values that differ between systems (e.g. a customer record number in your sales system vs. your billing system)
• List Properties — Used for parent/child hierarchies (e.g. a sales order with header data and line items)

TIP

Transaction Types tie directly to a Schema Definition and identify the actions to take on each data. See Data Models for details.

Configure Connectors

Connectors provide the security protocols to interact with specific software systems. When an Endpoint reads or writes data, it accesses the connecting system through an API. You'll provide the API credentials for each system that needs to connect to the Common Model.

WARNING

Secure settings data can typically be found in the Admin settings of the connecting system. Links to common third-party authentication documentation can be found in the Connectors Catalog.

Build Data Hubs

A Data Hub is a logical grouping of Endpoints forming a single integration solution. Build Data Hubs like modules — cluster logical groupings to make them straightforward and easy to maintain. Each grouping is typically based on a specific entity (e.g. Customers) or a business process (e.g. Lead to Cash).

Endpoints can publish data to the hub, subscribe to data from the hub, or be bi-directional. Once all Endpoints are added, you map each Endpoint Action to tell the Common Model exactly how to perform tasks — what data to get, where to get it, where to publish it, and the method to read or write it.

Example

Salesforce references website data as domain; NetSuite references it as url. The Common Model lets you map both systems to a Schema Definition called Website. When subscribing from Salesforce, it reads the domain field; when publishing to NetSuite, it writes to the url field.

Best Practice

Create as few or as many Data Hubs as necessary. Fewer mappings per hub means easier maintenance. Each Data Hub has its own version control and can be updated independently. Start small and consolidate as needed.

Templates

TeamCentral provides pre-configured Templates for common connectors. Templates tie specific Data Models to configured Endpoints and create basic mapping for you. When adding an Endpoint, select a Template if available, then choose which Schema Template and Transaction Type to apply.

WARNING

Templates do not necessarily pre-build mapping for the entire connection. You may need to build additional mappings for unique Schema Definitions related to your business.

Deploy and Monitor

When your configuration is ready, deploy the Data Hub to push it to a Live version. Data Hubs have internal versioning:

• Draft — A work-in-progress
• Live — A version running in production
• Previous Deploy — Previous Live copies

Once deployed, monitor integration health through the Dashboard, investigate individual Messages and Error Logs, manage the entity index, and configure Alerts for error notifications.