Objects

From LongJump Support Wiki

Objects are the basic building blocks used to collect information in Applications.

Objects often represent entities in the real world and are modeled based on specific delineations needed by the business. For example, if an application for tracking dogs is required, the Dogs object may define the characteristics of each dog. However, if tracking dogs and cats is required, it may be necessary to define the object as Pets. Or if the need is to track dogs, cats, zebras or trees, a Species object may need to be defined.

Alphabetical search is not available in Custom Objects, (but is available in Built-in or CRM objects)

The Create Campaign link is not available under the [More Actions] button, even if campaign tracking is enabled for this object, (but is available in Built-in or CRM objects)

How Are Objects Used?

The platform provides a framework for building information structures that can be used to house data and extract it for a multitude of purposes. Objects, and the data associated with these objects, are the primary information structures in an application.

Objects provide the ability to collect data and share it with other users (based on their team, user role, and access permissions that are assigned). Data is contained in fields, as a data entry form. Data can be typed directly into fields via a Form, or data can be imported from CSV files.

Once an object is created, its properties, field attributes, print templates, web forms, and other associated options can be modified.

Varieties of Objects

There are two kinds of objects:

Built-in Objects are pre-defined objects that come with the platform. For example: User, Team, Role.

CRM Objects are a special class of pre-defined objects that come with the CRM application. For example: Accounts, Contacts.

Custom Objects are created when applications are developed or installed.

Note:Most users will never be aware that there is a difference between those two kinds of objects. Even for developers, the distinction is often minor. In general, Custom Objects are more customizable. They allow subclassing, workflow processing, and provide a variety of other capabilities. Built-in Objects and CRM Objects, on the other hand, often provide specific functionality that is available only in those objects.

There are also two flavors:

The term object designates an entity that is built on a database table, with all of the features that the platform provides for manipulating them: Forms, Validations, Data Policies, Spreadsheet (grid) views, and more. Each table (object) has columns (fields), each row has cells, and each cell has exactly one value. That value may be an ID (foreign key) that lets you select records from a different table (connect to other objects via lookup fields). The field value may even be a comma-separated list. But when managing an object record, you are in effect dealing with a set of single values for a row in a spreadsheet.

A Composite Object, on the other hand, is a combination of Related Objects--objects that are connected by lookup relationships. For example, a customer has many orders and a choice of mailing addresses, while every order has a mailing address chosen from the list.

Depending on how you write your application, you can work with either simple objects or composite objects—-whichever makes the task easier.

Delete an Object

When an object is deleted, the associated Data Tab will not be available in your application. All of the records and Related Information in the object are deleted. Deleting an Object moves all associated records to the Recycle Bin.

To delete an object:

Click Designer > Objects > {object}

From the Properties tab, click the [Delete] button

Enter your name to confirm your action

Click [Delete] once again to delete the object, along with all of the records it contains.