# Change the model safely

> See what renaming, removing or reassigning types and elements does to existing entries and to the sites that read them, with tips for safe modelling.

You can change your content model at any time, even after entries are published. This page lists what each change does to existing entries and to the websites and apps that read them, and ends with tips for modelling. It is for project Owners.

## Who can change the model?

Only project Owners. Editors and Developers can open **Content model** and look at it, but the controls are switched off or hidden, and a note says so. An AI assistant can change the model only when an Owner connected it with the **Change the content model** permission, and it always previews first (see [What assistants can do](https://spatibase.com/docs/ai/what-assistants-can-do/)).

## Do model changes need publishing?

No. Changes to types, elements and map feature types are not drafts: they apply as soon as you save, including in the Content Delivery API. Removing an element from a type, for example, removes that field from the API for every entry of the type straight away. Only entry content and groups go through draft and publish, and changes to the model are not part of a [version](https://spatibase.com/docs/publish/versions/): going back to a version does not undo them.

> **Important:** Before changing an identifier or removing something a website uses, check with your developer. Websites and apps read your content by identifier. If your developer generated a typed client from the project's [typed OpenAPI file](https://spatibase.com/docs/reference/delivery-api/#machine-readable-spec), they regenerate it after you change types, fields or options.

## What happens to my entries when I change the model?

Spatibase never silently throws away values that editors entered. Here is what each change does:

| You do this | What happens to existing entries |
|---|---|
| Remove an element from a type | Entries keep the stored values, but the entry form and the API stop showing them. Assign the element again and the values reappear. |
| Archive an element | It is removed from every type that uses it, and the values are kept. Restore it with **Show archived** and assign it again to bring them back. |
| Change an element's **Identifier** | The field is renamed in every entry. Apps that read the old key stop working, and the form warns you before you save. |
| Change an element's settings (remove a Choice option, switch off a range or several options, change a date mode) | Stored values that no longer fit are kept as they are. The entry form shows a notice on that field so an editor can decide what to do with the value. A removed Choice option, or one whose value changed, shows nothing in the API for those entries until an editor picks a current option. Before saving, the element editor says how many entries use it (and how many are published) and asks you to confirm. |
| Remove a language from **Languages** | Its translations are kept but hidden in the app and the API. Add the language again and they come back. Turning languages off keeps them too. |
| Mark an element **Required** | Drafts still save without it. Marking an entry ready to publish needs it filled in. |
| Change a type's **Identifier** | Apps that use the old key stop finding the type. The form warns you before you save. |
| Switch a type to **No location** | The map tools are hidden for its entries, and any stored location is cleared the next time an entry is saved. The API shows no location for these entries right away. |
| Change a type's **Allowed shapes** | Existing shapes stay as they are, and the published copy keeps showing. An entry whose shape no longer fits must get a new shape the next time it is saved or marked ready. |
| Move a type under another **Parent type** | It gets the new parent's elements and no longer the old parent's. Values of elements it no longer has are kept. Elements it had of its own that the new parent already has become inherited. |
| Turn a type off (switch off **Show in Entries and the API**) | Its entries, and those of its subtypes, stay editable but leave the API until you turn it on again. |
| Delete a type | Not possible while it still has entries or subtypes, or while a **Reference** element links to it. Its elements stay in the **Elements library**. |
| Edit a map feature type (name, icon, color) | Shapes already drawn take on the new look, in the API too, without publishing. |
| Delete a map feature type | Not possible while a **Map shapes** element offers it or a shape in an entry (draft or published) uses it. |

### What can't be changed?

A few settings are fixed once created, because stored values depend on them:

- an element's **Kind of content**;
- a map feature type's **Identifier** and kind of shape (point, line or area).

To change one of these, create a new element or map feature type and move the content over.

## What can an identifier look like?

Types, elements and map feature types each have an **Identifier** that apps use as a key. It must:

- use lowercase letters, numbers, `-` and `_`, and start with a letter;
- be at most 64 characters long;
- differ from the identifiers of the other types, elements or map feature types in the project (an archived element keeps its identifier);
- for an element, not be one of `id`, `title`, `type`, `geometry`, `status`, `createdAt`, `updatedAt` or `publishedAt`, which the API already uses.

If you leave the suggestion alone, Spatibase makes sure it is free, adding `-2`, `-3` and so on when it is not.

## Tips for modelling

A good model is easy for editors to fill in and stable for the websites that read it.

- **Name elements for editors, key them for developers.** A label such as "Opening hours" is for people; keep the identifier short and stable (`opening-hours`), because apps depend on it.
- **Reuse elements.** Create "Description" once and assign it to every type that needs one. One element means one setting to maintain.
- **Use subtypes when types share most details.** "Park" and "National park" share almost everything, so make one a subtype of the other. Use separate types when they share little.
- **Use Choice instead of free text for anything people filter by.** A list of options keeps values consistent: one "Wi-Fi", never three spellings.
- **Decide early whether something is a place.** A type with a location appears on the map; a type with **No location** is content only, such as articles or FAQs. Changing this later clears stored locations.
- **Add a Required rule only where it matters.** Required elements block publishing, so mark only what a website really needs.
- **Turn off instead of deleting.** Switching off **Show in Entries and the API** hides a type from the API and from new entries without losing anything.
- **Start from a template if one is close.** The **Store locator**, **Trails & outdoor spots** and **Events map** templates show a working model you can adapt. See [Create a project](https://spatibase.com/docs/get-started/create-a-project/#start-empty-or-from-a-template).

## Related

- [Types](https://spatibase.com/docs/model/types/)
- [Elements](https://spatibase.com/docs/model/elements/)
- [Map feature types](https://spatibase.com/docs/model/map-feature-types/)
- [Drafts and publishing](https://spatibase.com/docs/publish/draft-and-published/)