360Crafter Documentation

Search for the articles here or browse the categories below.

Browse by topic

Find guides, tutorials, and answers organised by category.

Popular articles

What other people are reading right now.

Getting Started

Presets

Presets allow you to reuse styling and behavior across multiple hotspots or skin components. Instead of manually copying colors, fonts, borders, actions, and other settings from one element to another, you create a preset once and link it wherever you need it. When you later update the preset, every linked hotspot or skin component is updated automatically. In other design software, presets may also be referred to as (design) tokens or (combo) classes. Hotspot Presets vs. Skin Presets 360Crafter contains two separate preset systems: - Hotspot Presets - Skin Presets Although they are managed independently, they work exactly the same way. Everything explained in this article applies to both systems. Preset Types Each hotspot or skin component can use three types of presets: - Unique - Custom - Defaults These presets work together in a priority system, where higher-priority presets override lower-priority ones. Unique Preset The Unique preset contains styling and actions that apply only to the currently selected hotspot or skin component. Use it when an individual element needs to look or behave differently from everything else. For example, if one hotspot should have a purple background while every other hotspot remains unchanged, configure that color on its Unique preset. The Unique preset always takes highest priority over other presets. Defaults Preset The Defaults preset defines the starting appearance and behavior for a specific hotspot or skin type. Each hotspot type has its own defaults. For example: - Text Hotspots - Icon Hotspots - Video Hotspots Changing a Defaults preset only affects newly created items of that type. For example, if you change the Icon Hotspot Defaults preset to have: - a white background - a circular shape Every new Icon Hotspot you create will automatically start with those settings instead of the standard appearance. The Defaults preset always takes the lowest priority compared with other presets. Custom Presets Custom presets let you create reusable styles that can be shared across multiple hotspots or skin components. Create one by clicking the + button located between Unique and Defaults, then give it a descriptive name, such as: - Project Card Hotspot - Navigation Button - Warning Marker Once linked, every hotspot using that preset shares the same styling and actions. For example: - one preset could create white circular hotspots with a green border - another could create red squares with 5 px rounded corners Editing the preset later automatically updates every linked hotspot. The Custom preset takes higher priority than Defaults but lower priority than Unique. There can be multiple custom presets on a single hotspot or skin component. The last linked custom preset takes priority over the custom presets that were already added before. Preset Priority When multiple presets define the same property, the preset with the highest priority wins. Priority is always: 1. Unique 2. Custom Presets (top to bottom) 3. Defaults This means: - Unique always overrides Custom and Defaults. - Custom presets override Defaults. - If multiple Custom presets are linked, the one higher in the list takes precedence. If you want to change the order of Custom presets, unlink the preset and link it again. Newly linked presets are placed above older ones. Understanding Preset Indicators The Properties panel uses color indicators to show where each value comes from. Blue A blue-highlighted property belongs to the currently selected preset. Any changes you make will be stored in that preset. Orange An orange-highlighted property is inherited from another preset. Hover over the property to see which preset supplies the value. Red (Strikethrough) A red property with a strikethrough indicates that the value exists but is currently overridden by a higher-priority preset. For example: - The Unique preset sets the background color to purple. - Your Project Card Hotspot custom preset sets the background color to white. Because Unique has a higher priority, the hotspot appears purple. If you later remove the purple background from the Unique preset, the hotspot automatically falls back to the white background defined in the Project Card Hotspot preset. Presets for Design and Actions Presets are not limited to visual styling. They can also contain Actions. For example, imagine a hotspot that triggers a notification. - If the notification action is added while the Unique preset is selected, only that hotspot will trigger the notification. - If the notification action is added to a Custom preset, every hotspot linked to that preset will automatically inherit the same action. This makes presets useful for maintaining both a consistent appearance and consistent behavior throughout your project.

Getting Started

CMS

The CMS (Content Management System) is a structured data layer built into every 360Crafter project. Think of it as a spreadsheet that lives alongside your experience. You can store any information in it, such as product names, prices, descriptions, images, audio files, and locations, and then connect that data directly to hotspots, panoramas, and other elements in your tour. This separation of content from design means you can update text, swap images, or change values without touching the visual layout of your experience at all. Tables, Fields, and Records The CMS is organized around three concepts: Tables (also called collections or datasets) are the top-level containers. Each table holds one category of information. A project might have a “Products” table, a “Status” table, or a “Team Members” table. Fields are the columns of a table. Each field has a name and a type (text, number, image, and so on). The field structure defines what kind of data a table holds. Records are the rows of a table. Each record is one entry: one product, one status, one team member. Built-in Tables Every project automatically gets three tables that 360Crafter creates and keeps up to date for you: Panoramas contains one record for each panorama in your project, with fields like name, thumbnail, file URL, dimensions, and order. Hotspots contains one record for each hotspot, with fields like name, type, position, the panorama it belongs to, and its applied presets. Group Hotspots contains one record for each hotspot group, with fields like name, type, panorama, parent group, and child count. You cannot delete these built-in tables. They are regenerated automatically whenever you add, remove, or change panoramas or hotspots. You can add your own custom fields to extend them. For example, you could add a “Location” field to the Panoramas table or a “Product SKU” field to the Hotspots table. Field Types When you add a field to a table, you choose its type. The available types are: | Type | What it stores | | ------------- | --------------------------------------------------------------- | | Text | Short plain text | | Long Text | Multi-line or rich text | | Number | A numeric value, with options for decimal places and formatting | | Integer | A whole number | | URL | A web address | | Color | A color value | | Image | An uploaded image (JPG, PNG, WebP) | | Audio | An uploaded audio file (MP3, WAV, AAC, and others) | | Date | A date, with configurable display format and timezone | | Date & Time | A date and time | | Switch | A true/false toggle | | Single Select | A choice from a fixed list of options you define | | Linked Field | A reference to one or more records in another table | Linked Fields A linked field creates a relationship between two tables. For example, if you have a “Products” table and a “Categories” table, you can add a linked field to Products that points to a row in Categories. Each product record then references its category. When you set up a linked field, you choose whether it connects one record to one other record, or one record to many. Linked fields work in both directions. If Products links to Categories, you can also access which products belong to a given category from the Categories side. Localization Text and URL fields can be marked as localizable. When a field is localizable, it stores a separate value for each language your project supports rather than a single value. For example, a localizable “Description” field on a panorama might store “Kitchen” in English and “Küche” in German. When a viewer switches the tour language, all localizable fields automatically display the correct translation. You configure which languages your project supports in the project settings. The active language in the editor can be switched at any time to preview how the experience looks in each locale. Editing CMS Data The CMS Page Open the CMS page from the project sidebar to see and edit all your tables. The interface works like a spreadsheet: you can add and remove columns, edit cells directly, import data from a CSV or JSON file, and manage all records in one place. Quick Edit from the Editor When you select a hotspot in the editor, the Properties Panel includes a CMS tab. This tab shows the custom fields for that hotspot’s record and lets you edit them without leaving the editor. Changes are saved immediately and are reflected anywhere that field is used in the experience. Using CMS Data in Your Experience CMS data becomes useful when you connect it to visible content in your tour. You can reference any CMS field in a text field using the [table.field] token syntax. For example, placing [hotspot.name] in a hotspot label inserts that hotspot’s name from the CMS. Placing [panorama.location] in a description inserts the location field from the Panoramas table for the current panorama. This is covered in detail in the Dynamic Linking article. Collection Lists A collection list is a special skin component. It connects to a CMS table and renders one copy of its contents for each record in that table. This lets you build dynamic lists, galleries, or menus that are driven entirely by CMS data. You can create a menu by having 3 text component A, B and C as their own duplicated menu items in the skin and linking them to panoramas A, B and C. Or you can put in a single Collection List with 1 text component. In which you link the collection list to the panoramas. Now when you import later panorama D, it is automatically shown up as well in the menu. You can also configure filters and sorting on a collection list to control which records are shown and in what order.

Getting Started

Variables

Variables are named, reusable values you define once and apply throughout your project. Instead of manually typing the same color code or number in dozens of places, you set up a variable with a meaningful name and reference it wherever you need it. When you update the variable, every place that references it updates automatically. Why Use Variables? Presets handle consistent styling within a single hotspot type, but variables go a level above that. If your brand color appears across multiple different presets (a callout preset, a menu preset, a tooltip preset), updating one variable updates all of them at once without touching each preset individually. And at the craftspace level, a single variable change can ripple across every project in your craftspace simultaneously. Variable Types 360Crafter supports three types of variables: Color Stores a hex color value (e.g. #3B82F6). Color variables are the most commonly used type. Apply them to backgrounds, text, borders, icon tints, and any other color property in the editor. Number Stores a measurement or rotation value, such as 20px or 50%, or a number of degrees. Use number variables for consistent spacing, border radius, font sizes, rotation, or any other measurement that repeats across your project. Icon Stores a reference to an icon. This can be a URL, an uploaded image, or a built-in Lucide icon using the format lucide:icon-name. Icon variables let you swap out a symbol globally across all hotspots that reference it. Scopes: Craftspace vs. Project Variables exist at two levels: Craftspace variables are shared across all projects in your craftspace. They are ideal for brand-wide values like your main brand colors, your company icon, and your standard sizing. Everyone working in the craftspace can use them. Project variables are local to a single project. They are perfect for values specific to one experience, such as a scene-specific color palette, a unique icon set for that tour, or sizing that differs from the craftspace defaults. When a project variable and a craftspace variable share the same name, the project variable takes priority. This lets you override a craftspace default for a specific project without affecting anything else. Managing Variables Craftspace Variables Open the Craftspace settings to manage variables shared across all your projects. Here you can create, edit, and delete colors, numbers, and icons at the craftspace level. Project Variables Open the Variables page within a project to manage that project’s local variables. You will also see a read-only view of craftspace variables here, so you can see everything available to your project in one place. Using Variables in Properties When editing a hotspot or other element in the Properties Panel, you will see variable options in color pickers and numeric fields. - Color fields show a list of your color variables. Click one to apply it. The field stores a reference to the variable rather than the raw color value, so if you update the variable later the element updates too. - Numeric fields show a variable picker when variables of the matching type are available. Select a variable to link the field to that value. A Built-in Variable: circle 360Crafter includes one built-in variable available to all projects: circle. It stores the value 999px, which produces a fully circular border radius when applied to an element. You will see it appear in border radius fields alongside your own variables. Tips - Name variables for intent, not appearance. brand-primary is better than blue-500. If you rebrand to a different color, the name still makes sense. - Use craftspace variables for anything brand-wide. Reserve project variables for one-off overrides or project-specific values. - Project variables override craftspace variables by name. To customise a craftspace default for one project, create a project variable with the exact same name. - Variables are live. Editing a variable value immediately updates every place it is referenced in your project. You do not need to re-apply it manually.

Getting Started

Dynamic Linking

Dynamic Linking is the way you connect dynamic data (both CMS and Variables) to content in your experience. Instead of typing a fixed value into a text field, you insert a token that pulls its value from somewhere exlse: a CMS field, a variable, the name of a linked target, and so on. When that source value changes, the content updates automatically everywhere it is used. The Token Syntax Tokens follow the pattern [source.field], where source is the data table or system you are pulling from, and fieldis the specific piece of data you want. For example: - [hotspot.name] inserts the name of the current hotspot from the CMS - [panorama.location] inserts the location field of the current panorama - [var.brand_primary] inserts the value of a variable named “Brand Primary” Where You Can Use Tokens Tokens work in any text field that supports rich content. This includes hotspot labels, descriptions, tooltips, and custom HTML fields. When you are in one of these fields, type [ to open the autocomplete menu. The menu shows all available sources and fields. You can keep typing to filter the list, then press Enter or click to insert the token. Available Sources Hotspot Resolves fields from the current hotspot’s record in the Hotspots CMS table. [hotspot.name], [hotspot.type], [hotspot.panorama_name] Any custom field you have added to the Hotspots table is also available here. Panorama Resolves fields from the current panorama’s record in the Panoramas CMS table. [panorama.name], [panorama.location], [panorama.time] Any custom field you have added to the Panoramas table is also available here. Target Resolves the name of the panorama a navigation hotspot links to. [target.name] Group Resolves fields from the parent group hotspot’s record in the Group Hotspots CMS table. Useful when a hotspot is nested inside a group and you want to display information about that group. [group.name], [group.panorama_name] You can also traverse up to a grandparent group using [group.parent.field]. Collection Resolves fields from the currently active row inside a collection list component. This source is only available inside the content of a collection list, where each item represents one record from the connected CMS table. [collection.name], [collection.price], [collection.image] Variable Resolves the value of a project or craftspace variable. [var.brand_primary], [var.border_radius] Variable names are normalized to snake_case. A variable named “Brand Primary” is referenced as [var.brand_primary]. Linked Fields If a CMS table has a linked field pointing to another table, you can traverse that link inside a token using dot notation. For example, if the Hotspots table has a linked field called “Status” that references a “Status” table with a “label” field, you can write: [hotspot.status.label] This resolves the label from the linked Status record for the current hotspot. How Values Are Resolved Numbers are formatted according to the field’s settings, including decimal places, thousands separators, and separator style. Localizable fields resolve to the value for the currently active language. If no translation exists for the active language, the default language value is used as a fallback. Image and audio fields resolve to a working URL, so you can use them directly as the source of an image or audio element in custom HTML. Variables resolve to their raw value: a hex code for a color variable, a pixel value for a number variable, and so on. Tips - Use [panorama.name] in a hotspot label to automatically show the name of the destination panorama on a navigation hotspot, without ever typing it manually. - Use [collection.field] inside a collection list to build a fully data-driven gallery or menu where every item is pulled from a CMS table. - Localizable fields update automatically when the viewer switches language. You do not need separate tokens per language.

Tutorials

Dynamic hotspots in 360Crafter

Set a hotspot status from Available to Sold. And see how beside the text also the color dynamically changes by using the concept of linked fields. https://www.youtube.com/watch?v=CqRNFS6IFhw

Integrations

Baserow

Connect Baserow to 360Crafter CMS Use a Baserow grid view as the data source for a CMS table. Baserow is the most robust source 360Crafter supports: syncs are instant (no publish cache), rows keep a stable identity even when renamed, and all you need is a share link. Set up the view 1. In Baserow, open the table’s grid view and click Share view. 2. Click Create a public link and copy it. It looks like https://your-baserow.example.com/public/grid/…. 3. Optionally, protect the link with a password in the share settings. The view controls what 360Crafter sees: hidden columns and filtered-out rows are not imported, so you can share exactly the slice of data your tour needs. Import the view 1. In the CMS, click Add or import → Baserow (shared view). 2. Paste the public link. If the view has a password, enter it in the View password field — it’s remembered, so future syncs won’t ask again. 3. Click Fetch and preview, check the detected field types, and import. Rich Baserow values come through in a readable form: select options and linked rows arrive as their labels, checkboxes as true/false, and file attachments as URLs. Linking rows to panoramas or hotspots A column can become a Linked field: in the preview, set its type to Linked field and pick the target table (for example Panoramas). Fill the column in Baserow with the target’s names — 360Crafter matches them to the actual records on every import and sync. Use commas for multiple links. Names that don’t match anything stay visible as text so you can spot and fix them. Keeping the table in sync Open the table tab’s dropdown and click Sync from Baserow. Syncing: - Updates all columns that come from Baserow. These are marked with a small lightning icon ⚡ in the column header — Baserow owns them, and any edits you made to their cells in the CMS are overwritten. - Keeps fields you added manually in 360Crafter, including their values. They have no lightning icon and are never touched by a sync. - Adds new Baserow columns after asking you for their field types, and removes columns you deleted from the view. Renaming rows is safe Every Baserow row has a stable internal id that 360Crafter stores during import and sync. Rows are matched by that id, so you can freely rename rows in Baserow without losing manually added field values or breaking links that point at them. (This is a key difference from Google Sheets, where the first column acts as the row key.) Live data in published tours By default, exporting a tour takes a snapshot of your table — later Baserow edits don’t affect it until you export again. To make published tours always show the current Baserow data, enable Keep synced in exported tours — either in the table tab’s dropdown or in the Data Connections overview of the export window. When enabled, each visitor’s browser fetches the view directly from your Baserow server when the tour loads: - Changes in Baserow appear on the next tour reload — instantly, with no re-export and no publish delay. - The tour depends on your Baserow server: every visit makes requests to it, and its address (including the view link) is visible to visitors. If it’s unreachable, visitors see the data as it was at export time. - Turn the option off to go back to static snapshots (takes effect on your next export). Password-protected views can’t be live Live sync would ship the view password inside the tour, where any visitor could read it. 360Crafter therefore refuses to enable Keep synced in exported tours for a protected view and asks you to remove the password first (Baserow → Share view settings). Password-protected views work normally for syncing inside the editor — the password just never leaves your project. Good to know - Self-hosted Baserow has no API limits — each tour visit costs your server only a couple of small requests. On Baserow Cloud, very high simultaneous traffic could run into its concurrent-request fair-use limit; heavily trafficked tours are better served by a static snapshot. - Images and audio referenced by URL in a live-synced table load directly from wherever they’re hosted, so use stable, public URLs. Troubleshooting | Problem | Fix | | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | ”Make sure the grid view is shared publicly” | The link isn’t a public grid view link. Use Share view → Create a public link and copy it. | | ”The Baserow view password is incorrect” | The password changed. Re-import the view with the current password. | | ”This Baserow view is password protected” during live sync | The view got a password after it was set to live sync. Remove the password, or disable live sync for the table. | | Linked field shows plain text instead of a pill | The name in Baserow doesn’t match any record in the target table — check spelling. |