--- title: Decide between a built-in record and your own Object url: https://tideswell.xyz/docs/objects/built-in-or-your-own description: Work out whether the thing your team is tracking already has a home in Tideswell, or whether it needs an Object you define yourself. --- > Documentation index: fetch https://tideswell.xyz/llms.txt to discover every page before exploring further. # Decide between a built-in record and your own Object An **Object** is a kind of record your team defines, built by an admin in **Settings › Objects** and listed under the **Objects** group in your sidebar. explains what one is and why it exists. Tideswell also arrives with the records most brands need already built, so before you define an Object of your own, spend five minutes checking whether the thing you are tracking already has a home. Putting it in the right place first saves rebuilding it later, and a built-in record comes with screens and connections you would otherwise recreate by hand. ## What comes built in? [#what-comes-built-in] Fourteen kinds of record come with your workspace: Tasks, Campaigns, Purchase Orders, Suppliers, Customers, Orders, Products, Variants, Inventory Levels, Wholesale Accounts, Wholesale Orders, Decisions, Members and Callbacks. Each one has its own list, its own screens, and its own setting for who can see and change it. They split into three groups, and the group matters when you are deciding: * **Filled from your store.** Customers, Orders, Products, Variants and Inventory Levels mirror what is in Shopify. You read them in Tideswell, you filter them, you link work to them, and they stay current on their own. * **Written by your team.** Purchase Orders, Suppliers, Wholesale Accounts, Wholesale Orders, Tasks, Campaigns, Decisions and Callbacks are the ones people fill in as they work. * **Your people.** Members is the list of everyone in the workspace, which is what the owner picker and the person fields read from. ## When does a built-in record already cover it? [#when-does-a-built-in-record-already-cover-it] Six things already have a home: a purchase from a factory, a supplier and its terms, a wholesale account, a customer, a product, and one piece of work with an owner and a due date. Use the built-in record for any of those, and put your effort into its stages and its permission dials instead. Fairgreen Golf Co. buys 1,200 quarter zips from Portside Mills. That is a purchase order, not an Object called Factory Orders. Portside itself is a supplier, with its lead time and payment terms on the supplier record. The pro shop in Scottsdale that takes 40 polos a season is a wholesale account, and each season's order is a wholesale order. The clearest sign that a built-in record fits is that you are about to recreate fields that already exist. If your sketch has a field for the supplier's lead time, and the supplier record already carries lead time, you are duplicating rather than defining. Merchandising teams do this most often with purchase orders, because their old spreadsheet had a tab per factory and Tideswell does not need one. You still get to shape a built-in record. Rename and reorder the stages a purchase order moves through so they read in your team's words, and set exactly who may view, create, update and archive each kind of record. See . ## When should you define your own Object? [#when-should-you-define-your-own-object] Define your own when you are tracking many of the same thing, each one carrying the same handful of facts, and nothing built in is about that thing. If it currently lives in a spreadsheet with a header row, that header row is usually your field list. At Fairgreen, four things qualify: * **Repairs.** A customer sends a jacket back. You record who, which item, what is wrong, who is fixing it, and when it went out again. * **Fabric trials.** A mill sends swatches. You record the mill, the weight, the hand feel, a verdict and a date, and at the end of the year you want to know which mill wins. * **Press loans.** A jacket goes out to a magazine and you want it back. * **Store visits.** The sales rep calls on a golf shop and writes up what they saw. Four questions settle it, and we would answer them before opening Settings. Do you want to count them? Do you want to filter them, by mill or by month? Do they move through stages, from received to resolved? Does more than one person need to look at the same list? If the answer is yes to most of those, it is an Object. Sketch the fields first with , then build it with . ## Is it really an Object, or just a task? [#is-it-really-an-object-or-just-a-task] This is the call people get wrong most often. A task is one piece of work with an owner and a due date, done once and then closed. An Object is a kind of thing that keeps existing, that you want a list of, and that you want to filter and count long after any one piece of work on it is finished. "Chase the mill for the navy swatch by Friday" is a task. "We ran 30 fabric trials this year and I want to know which mill wins" is an Object. The giveaway is the plural: if the sentence you want to say out loud starts with a number and a plural noun, you want an Object. The two are not rivals. A fabric trial can have three tasks hanging off it, and a task can point at the trial it belongs to, so the person doing the work sees the context and the record shows the work in flight. That is covered in . ## What do both kinds have in common? [#what-do-both-kinds-have-in-common] More than you would expect, which is why the decision is lower stakes than it feels. Built-in records and the Objects you define get the same core behaviour, so you are not choosing between a rich option and a thin one. Both kinds get: * A list you can search, filter and save a view of. See . * Stages a record moves through, in your own wording. * An owner, which can be a person, a team, both or neither. See . * Comments and a history of what changed. * Links to anything else in the workspace, in either direction. See . * Their own dials for who may view and change them, so one list can be open to everyone and another held to leads. See . The real difference is the fields. A built-in record arrives with its fields already decided, which is what lets it stay in step with your store and work the same way in every workspace. On an Object you define, the fields are entirely yours: you choose them, their types and their order. That is the whole reason to define one. ## Decide in this order [#decide-in-this-order] Run these five steps and you will land in the right place. It takes about two minutes, and it is worth doing before anyone opens the builder. 1. Say the thing out loud in your team's own words. "Repairs." "Fabric trials." "Purchase orders." 2. Look down the sidebar and the list in **Settings › Objects** to see what your workspace already has. Somebody may have defined it last quarter. 3. Ask whether it is one piece of work or a kind of thing. One piece of work is a task. 4. Ask what you would want to filter, count or group by in six months. That answer tells you the fields, and sometimes tells you the thing already exists somewhere else. 5. If it needs an Object of its own, sketch the fields before you build anything, because a field's type is fixed once you save it. If you are still unsure, define your own. An Object you defined and stopped using can be retired quietly, and its records stay where they are: see . Squeezing something into a built-in record that was never about it is the harder position to unwind.