Overview
Before you begin adding custom objects to Rippling, take the time to create a data model.
A custom object is a custom dataset that you create in Rippling to store information that’s unique to your company. The custom objects you create become part of the Rippling data model and live alongside native Rippling data. For more information, see Get started with custom objects.
A data model defines the structure and organization of your custom data, including:
- The objects you need to create
- The fields that belong in each object
- The relationships between objects
When you want to add custom datasets to Rippling, creating a data model is an important first step. Whether you’re building a custom app or adding data to power analytics, the data model determines what you’ll be able to do with your data once it’s in Rippling.
Thoughtfully planning your data model will help you achieve your goals while reducing the likelihood that you’ll need to do a costly restructure down the road.
Creating a data model is an art, not a science. There are usually many variations that will work, but there are tradeoffs. Data models that split things up into several different objects offer a lot of flexibility and will allow you to adapt quickly to changing requirements. However, models that keep things more consolidated may be easier to understand, use, and maintain.
Identify your requirements
- Are you building a custom app to improve a process? Who is involved in the process? What information do people need at each step?
- Are you importing data to feed a specific set of metrics? How will you calculate those metrics? What data points will you need to build them?
Think through specifically what you want to accomplish by bringing the data into Rippling. Then, use those specifics to create your data model.
You’ll create your data model in three steps:
- Identify your objects and fields.
- Assign field types to each field.
- Select your name and owner fields.
Identify your objects
Start by listing the objects you know you’ll need. Typically you’ll need one object for each noun/entity in the data. For example, if you’re creating a custom app to track consulting projects, you know you’ll need objects for:
- Project
- Client
Other examples of custom objects might be a license, ticket, vehicle, incident, or invoice.
Identify your fields
For each object, list the data points you need to collect. These will be the fields on the object.
For example, each project needs information like the start and end date, status, and budget. Each client needs information such as a location, status, and account manager.
Project
- Project name
- Start date
- End date
- Status
- Budget
- Client
- Project Manager
- PM’s email
- Total costs
Client
- Client name
- Location
- Status
- Account manager
More examples: Fields on a custom object called License might include license type, issuing body, and expiration date. Fields on a custom object called Incident might include incident date, incident type, and affected customer.
Select a type for each field
Now that you’ve listed out the fields you want to collect, select a type for each field. You can add the following types of fields to custom objects:
- Basic field
- Lookup field
- Simple formula field
- Summary field
See Fields for definitions, data types, and default fields.
Basic field
Basic fields contain static data in a format you specify. You can add basic fields for things like text, rich text, dates, multichoice, and URLs. You can also upload files using basic fields.
For example, the project Start date will be a basic field with a data type of Date. The Status should be a basic field with a data type of Choice so you can ensure the values are the same across your dataset.
Project
- Project name | Text
- Start date | Date
- End date | Date
- Status | Choice
- Budget | Currency
- Client
- Project manager
- PM’s email
- Total costs
Client
- Client name | Text
- Location
- Status | Choice
- Account manager
Lookup field
A lookup field lets you create relationships between two objects. Lookups link together your data in Rippling. When a lookup exists, you can populate a value in one object by looking it up in another object, or display related information on records. You may want to create a lookup in these circumstances:
- You have more than one custom object and you need to link them together.
- You want to link an employee, department, or team to a custom object.
For example, you can create lookups to link the associated client with a project, and to link each project manager to their assigned projects.
Project
- Project name
- Start date
- End date
- Status
- Budget
- Client | Lookup to Client
- Project manager | Lookup to Employee
- PM’s email
- Total costs
Client
- Client name
- Location
- Status
- Account manager | Lookup to Employee
Think through the relationships in your data before you add lookups. The type of relationship dictates where you should add the lookup. This activity may also help you uncover additional objects you need. For example, if your data contains a many-to-many relationship, you will need an additional object to model the relationship. For more information, see Lookups and relationships.
Simple formula field
Using simple formula fields, you can automatically calculate field values. If there is data already in Rippling that you want to use, or a variation of some existing data that you want to create, consider using a simple formula field.
For example, you can use a simple formula field to automatically populate the project manager’s email address from their profile in Rippling.
Project
- Project name
- Start date
- End date
- Status
- Budget
- Client
- Project manager
- PM’s email | Simple formula field
- Total costs
Client
- Client name
- Location
- Status
- Account manager
Custom objects also support formula fields, but in the vast majority of cases, you should use a simple formula field instead. For more information, see Formula fields.
Summary field
A summary field lets you summarize related records by calculating a sum, count, minimum, or maximum. Use a summary field rather than a simple formula field any time you want to do one of these specific calculations. You must establish a parent/child relationship between objects before you can create a summary field.
For example, to calculate the total costs on a project, you could:
- Add another object called Expense that includes a field to capture the amount of the expense.
- Add a lookup on the Expense object to the project and enable a parent/child relationship on the lookup.
- Create a summary field on the Project object called Total costs that uses the lookup to the Expense object to calculate the total expenses captured for each project.
Project
- Project name
- Start date
- End date
- Status
- Budget
- Client
- Project manager
- PM’s email
- Total costs | Summary field
Client
- Client name
- Location
- Status
- Total revenue
- Account manager
Expense
- Expense name
- Date of purchase
- Description
- Amount
- Project | Lookup to Project
For more information, see Summary fields and Parent/child relationships.
Designate the name and owner fields
Every time you create a custom object in Rippling, a set of fields is automatically created with the object. These are standard pieces of information that are useful for any type of object. For more information, see Default fields.
Two of these fields are Name and Owner. You need to think about which of the fields in your data model should serve as the name and owner of each record.
Designate the name field in each object
The name field is a basic text field that serves as the display name for records in the object. It identifies the record and differentiates it from others. For example, the name of a project might be “Build out phase 1.” The name of a class might be “Intro to machine learning.”
In the Project and Client objects, the Project name and Client name fields are the name fields.
In other types of objects, there may not be a field that’s an obvious candidate to serve as the name. In these cases, you can set up auto-numbering to automatically generate a name. For example, in an object capturing class registrations, you could automatically generate a name for each registration event that includes a sequential number, such as Registration0001.
For more information, see Name field.
Designate the owner field in each object
The owner field is a lookup to the Employee object. It determines who has the ability to view and manage the record based on the permissions you set. You can think of this as the person who is responsible for the record.
In the Project object, the Project Manager field would be the owner. For the Client object, it would be the Account Manager field.
For more information, see Owner field.
Next steps
Once you’ve identified your objects and fields, selected a type for each field, and designated your name and owner fields, your data model is complete. You’re ready to add data to Rippling.