Frequently Asked Questions

If the upload fails, especially with large files, try the following:

• Start the upload and avoid switching to other browser tabs or windows during the process.
• Ensure your computer does not enter sleep mode — temporarily disable sleep if necessary.
• A stable internet connection is essential. Wi-Fi interruptions can cause uploads to fail.

File size alone is not a limitation.

You can also use a supported file-sharing option — a direct download link, Google Drive, Dropbox, or Yandex Disk. Instead of uploading the archive directly to the platform, simply provide a link to the file. Our platform will automatically download it from the link and start processing the project.

To locate the Leica database file, follow the steps below:

1. Launch Cyclone REGISTER 360.
2. In the project settings, specify the folder where your project is stored.
3. Open this folder in the file explorer. Inside, you should see a file named something like project_deliv_*.db.
4. After locating it, upload the database file to our platform together with your JPG panoramas to generate a virtual tour.

This file contains essential spatial data required for precise panorama placement and alignment.

A TXT file stores the position and orientation of your panoramas. Two layouts are accepted and automatically detected based on the file contents:

1. Position / orientation file (Leica)

One file per panorama, with exactly the same name as its image (for example, station_01.txt alongside station_01.jpg). It contains a position and an orientation:

position = [positionX, positionY, positionZ];
orientation = [rotationW, rotationX, rotationY, rotationZ];

Here is an example:

position = [-60.2344, 30.0544, -0.185128];
orientation = [0.804644, -8.74489e-06, -1.45999e-05, 0.593758];

The orientation is a quaternion in W, X, Y, Z order. Separate each value with a comma and a space, exactly as shown.

2. iQscene scene file

A single file that lists every panorama, recognized by the word iQscene on the first line. Two header lines follow, then one line per panorama, and the list ends with a closing brace }. The values on each panorama line are separated by spaces:

"path\to\station_01.jpg" posX posY posZ axisX axisY axisZ angle

The image path is quoted; posX posY posZ is the position, and axisX axisY axisZ together with angle (in degrees) describe the rotation as an axis and an angle. Example:

iQscene ...
...
...
"C:\Project\station_01.jpg" -60.2344 30.0544 -0.1851 0 0 1 90.0
"C:\Project\station_02.jpg" -58.1021 31.7765 -0.1820 0 0 1 92.5
}

Use a dot as the decimal separator and save the file in UTF-8 encoding. These structures let the platform place and orient your panoramas correctly in 3D space.

A CSV file stores the position and orientation of each panorama. Upload it together with the equirectangular JPG panoramas — the file name in every row (without its extension) must match the corresponding image. The platform auto-detects the layout, so several variants are accepted: A few things to keep in mind:

• Column names must match exactly (they are case-sensitive); their order does not matter, and any extra columns are ignored.
• qw, qx, qy, qz (and Orientation(W...Z), pano_ori_w...z) are the quaternion components in W, X, Y, Z order.
• rot_x, rot_y, rot_z (OmniSLAM) are Euler rotation angles expressed in radians.
• RIEGL and Lixel files are recognized by their file names (...ImageList.csv / ...panoramicPoses.csv); the remaining layouts are detected automatically from the header row.
• Use a dot as the decimal separator and save the file in UTF-8 encoding.

Here is an example of the generic comma-separated layout:

filename,x,y,z,qw,qx,qy,qz
station_01.jpg,-60.2344,30.0544,-0.185128,0.804644,-8.74489e-06,-1.45999e-05,0.593758
station_02.jpg,-58.1021,31.7765,-0.182004,0.799120,1.02000e-05,2.31000e-05,0.601171

Cyclone REGISTER 360
The image below shows the recommended settings when exporting your project to an LGSX file:

These settings help ensure compatibility and accuracy when using the file with our platform.

A point cloud composed of multiple scan stations must be preprocessed in FARO SCENE:

• Create Scan Point Clouds for each station to improve visualization.
• Disable the Edge Artifact Filter for clearer results.
• Register all stations and organize them into a single cluster.

Once this is done, export the cluster contents as shown in the screenshots below:

This process ensures correct alignment and compatibility when uploading to our platform.

Once your project is created, you can share it in several ways — all are available on the Project settings page.

The easiest option is to set the access mode to via link. In this case, registration is not required — anyone with the link can view the project.

Ideal for sharing with clients, stakeholders, or external reviewers without requiring them to create an account.

Yes — each project can be assigned a tag that works like a folder.

Use tags to group projects by client, sub-client, or any other category that helps organize your workspace. Note that only one tag can be assigned per project, so use a clear and structured naming convention.

The Links to other projects setting allows you to connect multiple independent projects within a single virtual tour.

For example, when navigating a virtual tour, users can click a transition and be instantly taken to a different project — such as a neighboring building, another floor, or a related location.

This feature is especially useful for large facilities or multi-site properties.

Here is a real-world example of this feature in use:
https://360-for-you.com/projects/HLxVEP0d/

Yes — we can activate a test subscription for you, valid for 2 weeks. This trial includes nearly the same features as the Pro plan and is ideal for testing large-scale projects.

If your scan file (for example, 100 GB) is already stored on Dropbox, Google Drive, or another supported platform, you can paste the download link when creating a new project. The system will automatically fetch and process the file — no manual upload required.

Yes — there are no country-based restrictions. If the website loads and works for you, you can use the service from Peru or any other location.
Feel free to try it out! You can create projects containing up to 10 setups completely free of charge.

Thank you for your interest — we greatly appreciate your questions and suggestions!

We currently handle all communication by email, as it allows us to track requests more efficiently and respond thoroughly. We are happy to continue the conversation this way and address anything you would like to discuss.

We look forward to your message!

Of course — here is a simple way to manually align your panoramas:

1. When capturing images, always orient the camera in the same direction relative to the cardinal points. For example, you can choose to keep the front of the camera facing "north" as you move through a space.
2. Upload photos to the platform. By default, all panoramas will be placed at the origin (0,0) of the coordinate system.
3. (Optional) To begin laying out the scene, move one of the setups along the X axis — for example, by 10 meters.
4. (Optional) Prepare a background image (for example, a floor plan) with a visible scale bar to make setup placement easier.
5. Upload the background image and align it using the scale bar.
6. Position each panorama in the room or area where it was captured.
7. Use the Delaunay triangulation option in setup settings to automatically link points.
8. Open any panorama and visually check whether the positions of the other setups appear offset.
9. In Coordinate settings, adjust the "Set view direction for all setups (degrees)" field to correct this. Start with your best estimate.
10. If the rotation goes the wrong way, try rotating again using the formula: -2 × initial guess.

This method gives you precise manual control over panorama placement — even without GPS data!

Watch this short video to see how fast and simple it is: https://youtu.be/IGucR18yJM4?si=2E1MyKhxYIDJG-PD

The issue is that Insta360 panoramas do not contain north-referenced orientation data, which is required to auto-generate correct directional links. There are several ways to resolve this:

1. Automatic orientation — for street-view projects where capture points are close together, try the "Use GPS coordinates to calculate rotation" feature on the platform.
   Example project captured with an Insta360 X4 and an external GPS module, processed automatically:
   https://360-for-you.com/projects/Ik3R7NWu/
2. Shoot in a consistent direction — if you always face the same way (for example, keep the front of the camera pointing "forward"), you can later adjust the global rotation angle manually to align links across all images.
3. Manual alignment per panorama — open each panorama, orient the view approximately north, and click the alignment button to set the correct view direction.
   You can do this using the editor linked from the "Basic settings" page of your project.

Note: These methods work only if GPS coordinates are available for each capture point.

Yes — an interactive map view is available for JPG panoramas that contain GPS coordinates in their EXIF metadata.

View capture locations on a map and quickly switch between points. This makes navigation more intuitive and the project context easier to understand, especially for outdoor or drone-based panoramas.

You can also enable the map view for any existing project, provided it has georeferenced coordinates. To do this, specify the EPSG code of your coordinate system in the project settings. Once set, the system will correctly interpret and display your geospatial data on the map.

Yes — to disable the map feature for a project, remove the EPSG code in the project settings. Once the coordinate system is cleared, the map will no longer be shown in the interface.

Yes — you can customize the background color of the level name (and other styles) using custom CSS.

In Profile settings, there is a field for entering a custom stylesheet. Once added, it will be applied automatically to all your projects.

Enter your stylesheet in this field using the same format as the placeholder example.

Yes — you can display live or recorded sensor data — temperature, humidity, vibration, occupancy, or anything else a device measures — directly on your panoramas.

What is MQTT, in plain terms?
MQTT is a lightweight messaging protocol widely used by sensors and IoT devices. A device publishes small messages (for example, a temperature reading) to a named channel called a topic, and anyone allowed to read that topic receives the value almost instantly. You do not need to run a server yourself — we host the message broker for you. Your device simply connects and sends values; the tour viewer connects and displays them.

How a sensor sends data to us
1. In Profile → API keys, create a key with the mqtt:publish permission. The key is shown only once — copy it.
2. Point your device or script at our broker. There are two ways to connect:

• Native MQTT over TLS — for physical sensors, gateways and most IoT libraries. Server address: mqtts://360-for-you.com:8883.
• MQTT over WebSocket (WSS) — for applications running in a web browser or in environments that only allow web traffic. Server address: wss://360-for-you.com/mqtt/.

Both connection methods are equivalent — choose whichever one your device supports. Use your numeric user ID as the username, and the API key as the password.
3. Publish your readings to a topic named users/<your ID>/sensors/<sensor name>. You may only write to your own branch — the <your ID> part must match your account.

How the data appears in a panorama
When you add a comment to a panorama, you can embed a sensor in it. From then on, users who are allowed to open that tour will see the sensor's latest value update live, without reloading the page. Access follows the tour: if the project is public or shared by link, anyone with the link sees the data; if it is private, only its owner, invited users and group members do. Making a project private automatically cuts off other users within seconds.

Embedding a sensor in a comment (the span tag)
To display a value, the project owner edits a comment on the panorama and inserts a small <span> tag pointing to one of their own sensor topics. The text you put inside the tag is shown as-is until the first reading arrives — use it as a label or a placeholder like a dash — and is then replaced by the live value. The simplest form is:

<span data-mqtt="users/<your ID>/sensors/temperature">—</span>

The value shown is exactly the message your device publishes (plain text), so format it on the device, for example 23.4 °C. The topic must be a specific one that your device publishes to — wildcards are not allowed in the viewer.

Optional attributes let you control how the value is displayed:

• data-mqtt-json="<path>" — if your device publishes a JSON object (for example {"temperature": 23.4, "humidity": 45}), use this to pick a single field. It supports nested paths such as weather.temperature and array indices such as readings[0].value. Without this attribute, the entire payload is shown as-is.
• data-mqtt-suffix="<text>" — appended to the value and useful for units. For example, data-mqtt-suffix=" °C" turns 23.4 into 23.4 °C.
• data-mqtt-show-last-update="true" — also show how long ago the value arrived, e.g. 23.4 (2m ago).
• data-mqtt-stale-after="<seconds>" — if no new reading arrives within this many seconds, the element is flagged as stale (a data-mqtt-stale attribute is added to it), so you can grey it out or highlight it with your custom CSS.
• data-mqtt-red, data-mqtt-yellow, data-mqtt-green — draw a small coloured dot before the value when the reading falls within one of the listed ranges (a "traffic light"). See Traffic-light indicator below for the range syntax.

A more complete example — pick the temperature field out of a JSON reading, append the unit, show how fresh it is, and mark it as stale after two minutes of silence:

<span data-mqtt="users/42/sensors/weather"
      data-mqtt-json="temperature"
      data-mqtt-suffix=" °C"
      data-mqtt-show-last-update="true"
      data-mqtt-stale-after="120">no data yet</span>

If your device splits readings across subtopics, point the tag to the exact one by appending the subtopic, e.g. users/42/sensors/weather/humidity. You can put several tags in one comment or spread them across different panoramas — each updates independently, and the same sensor can be embedded in as many comments and projects as you like.

Traffic-light indicator
To draw attention when a reading goes out of bounds, attach a coloured dot to the value. Set one or more of data-mqtt-red, data-mqtt-yellow, data-mqtt-green to a list of numeric ranges; the dot takes the colour of the first matching range, checked in the order red → yellow → green. If no range matches, no dot is drawn; if a colour has no range set, that colour is simply skipped. The ranges are not validated against each other — if they overlap, the red → yellow → green priority decides which colour wins; gaps result in no dot.

A range list is one or more expressions separated by ;. Each expression is one of:

• <X — value is strictly less than X
• >X — value is strictly greater than X
• <=X / >=X — same comparisons, but inclusive
• X-Y — value is between X and Y (both endpoints included); X and Y may be negative or decimal
• true, false, on, off — the payload exactly equals this word, case-insensitive — handy for binary sensors. Mix freely with numeric ranges in the same list, e.g. <0;>100;off.

Each condition matches only its own kind: numeric expressions require a number, while boolean tokens require that exact word. If no condition matches, the value has no dot. If you use data-mqtt-json, the extracted field is compared — not the whole JSON object.

For example, to flag a temperature as red below 0 °C or above 100 °C, yellow in the warning ranges (0-30 or 70-100), and green in the comfort zone (30-70):

<span data-mqtt="users/42/sensors/weather"
      data-mqtt-json="temperature"
      data-mqtt-suffix=" °C"
      data-mqtt-red="<0;>100"
      data-mqtt-yellow="0-30;70-100"
      data-mqtt-green="30-70">no data yet</span>

Security
All connections are encrypted. A device can only publish to its own topics, and the viewer can only read sensors embedded in tours the user already has access to. Revoking an API key stops new connections immediately (existing connections drop on their next reconnect).

If you would like help wiring up a specific device or dashboard, contact our technical support team and we will suggest the best integration approach for your project.

Yes — KNX values can appear on your panoramas using the same MQTT sensor support described above. KNX itself does not connect directly to the public internet (it lives on a wired bus inside your building), so a small KNX→MQTT bridge runs on your local network and forwards selected values to us. It is a one-time setup.

What you need

• A KNX IP gateway or router (KNXnet/IP, UDP 3671) on the same LAN as your KNX bus. Most modern installations already have one — ask your KNX integrator if unsure.
• A small always-on machine on the same network — a Raspberry Pi, a NAS that runs Docker, or any tiny Linux box.
• An ETS export (or just a list) of the group addresses and their datapoint types (DPT) for the values you want to publish. KNX is strictly typed: each address carries, for example, DPT 9.001 (2-byte float, °C) or DPT 1.001 (boolean) — the bridge needs to know which one.
• An API key with the mqtt:publish permission (Profile → API keys).

How it works

1. The bridge connects to your KNX IP gateway and listens to telegrams on the bus.
2. For each group address listed in its config, it decodes the raw bytes into a human-readable value using the DPT you supplied (e.g. 21.4 instead of 0x4C13).
3. It publishes that value to our MQTT broker over TLS/WSS on the topic users/<your ID>/sensors/<name you chose>, using your API key as the password.
4. In the tour, embed the value using exactly the same span tag as any other sensor — see Embedding a sensor in a comment.

Choosing a bridge
Several mature open-source projects can do this. One example is xknx (Python, also the engine behind Home Assistant's KNX integration), or you can find a standalone bridge by searching GitHub for knx mqtt bridge. Choose whichever option fits your hardware and skill level — any bridge that publishes to MQTT will work; the only requirements on our side are the topic name and the value.

Sketch of a bridge config
Most bridge configurations have the same basic structure: a KNX connection block, an MQTT connection block, and a mapping of group addresses to sensor names. A typical configuration looks like this:

knx:
  gateway: 192.168.1.10        # your KNX IP gateway

mqtt:
  url: wss://360-for-you.com/mqtt/
  username: "42"               # your numeric user ID, shown on Profile
  password: "sk_..."           # API key with mqtt:publish

mappings:
  - group: "1/2/3"
    dpt: "9.001"               # 2-byte float, °C
    topic: users/42/sensors/kitchen-temperature
  - group: "1/2/4"
    dpt: "1.001"               # bool, on/off
    topic: users/42/sensors/kitchen-light

Exact field names vary by bridge — consult its documentation. Map each KNX group to a friendly sensor name; that is the name you will write in the data-mqtt="..." attribute on the panorama.

Things to know

• The bridge runs on your network, not on ours. Once configured, start it as a service or a Docker container and it will keep publishing as long as your KNX bus is operational.
• Only the values listed in the bridge config leave your building. Everything not in the mapping stays on your bus.
• Revoking the API key in your profile stops the bridge from publishing immediately — useful if a device goes missing or you change installers.
• If a value is a JSON object rather than a plain number (some bridges publish {"value": 21.4, "unit": "°C"}), use data-mqtt-json="value" on the span tag to pick the field — see the previous question for details.

If you need help choosing a bridge or creating the initial configuration for your installation, contact our technical support team.

You can find a detailed PDF guide on how to use Potree's interface functionalities below: Open PDF in a new tab
Source: https://www.linkedin.com/pulse/complete-guide-potrees-interface-functionalities-abderrazzaq/

This guide covers the main tools and options in the Potree viewer to help you get the most out of point cloud visualizations.

Yes — even if your project is based on the metric system, it's possible to display measurements in imperial (US) units.

This is especially useful for teams working in international environments or presenting data to clients who prefer feet and inches. Display units can be switched in the viewer interface.

You can also set the default measurement unit in your profile settings. This ensures your selected format is applied automatically when viewing any project.

We agree — the ability to clean point clouds directly in the viewer would be extremely convenient, especially for removing artifacts such as steam clouds or passing vehicles.

With the current service architecture, this level of fine-grained editing is not technically feasible. Real-time point deletion in the browser would require a completely different processing model and data structure.

For now, external tools are recommended for point-level cleanup before uploading. Future options are being explored, but there is no timeline for this feature yet.

Your data is hosted in the European Union. Our main platform runs on servers located in Germany (operated by Hetzner, a long-established German hosting provider), so your data is processed in accordance with the EU GDPR.

Backups are stored in a separate data center, away from the primary server, so that an incident at one location cannot affect both your live data and its backup at the same time.

If you use a dedicated server, you can choose its location — Germany or Finland by default, or another region on request.

You are always in control of who can see each project. A project is visible only to the people you authorize — its owners, users and user groups — unless you deliberately make it accessible via link or fully public. For setup instructions, see Are there roles and permissions? and How can I share a project with a client?.

Aside from the people you grant access to, a small number of our support specialists may access a project only to help resolve a question or problem you have raised. They always do so under a strict confidentiality agreement (NDA).

Each project is access-controlled independently: a user only ever sees the projects they own or have been explicitly invited to, and there is no way to reach another customer's private projects.

On the shared platform, your data is logically isolated by account and protected by these access rules. If you require physical separation, a dedicated server hosts only your projects on hardware reserved exclusively for you (see What is a dedicated server and why do I need one?).

Yes. Access is controlled at two levels.

First, every project has a visibility setting: private (only authorized accounts), accessible via link (anyone with the link, no sign-up), or public.

Second, you assign roles: owners can view a project and change its settings; users and user groups can view the projects you share with them. You can also control who is allowed to leave comments on each project. This lets you give each team member exactly the access they need — and nothing more.

Backups run automatically and continuously, so your projects and account data are protected without any action on your part.

They are stored in a separate data center, away from the live server, so a problem in one location cannot affect both copies at once. In addition, a snapshot of the database is taken automatically before any change is applied to it.

The platform is monitored continuously, and its services restart automatically if one of them stops responding, so it can recover from short interruptions without manual intervention.

Your data stays safe regardless: because backups are kept off-site, the system can be restored to an earlier state even if a server is lost. Customers with strict availability requirements can also choose a dedicated server (see What is a dedicated server and why do I need one?).

Yes. We continuously monitor the health and performance of every part of the platform through dashboards and automated health checks, and we keep access logs. If a component becomes unhealthy, the issue is detected and the component is restarted automatically, while anything that needs attention is flagged for our team.

We keep the platform on the latest stable, security-patched versions of all its software components and libraries. Updates are reviewed and applied on a daily basis, so newly discovered vulnerabilities are addressed quickly rather than left to pile up.

We follow a fix-forward approach: if a problem appears after an update, we diagnose it and release a corrected version quickly instead of reverting the whole system. In practice, this restores normal operation faster than a traditional rollback.

Your data is protected independently of releases: a backup of the database is taken automatically before any change, and continuous off-site backups mean the system can always be restored to an earlier, known-good state if needed.

Yes — the platform is already used in production by paying customers every day.

It is hosted in the EU and served over encrypted (HTTPS) connections. The application runs in hardened, isolated environments with restricted permissions; access to every project is controlled; secret keys and credentials are stored in encrypted form; the platform is monitored around the clock; and backups are kept off-site. The same software also powers dedicated and self-hosted installations for organizations with stricter requirements.

All users currently share the resources of a single main server. When many users are active simultaneously, resources are distributed equally, which in rare cases may cause minor slowdowns. However, most users do not notice any impact.

A dedicated server is a separate physical server provisioned specifically for your use. Only your projects are hosted there — ensuring full performance, private data processing, and greater control over resources. It's a good option for teams with high data volumes, many users, or strict internal policies.

Yes — you can use your own domain. This option is available on all plans with a dedicated server.

You can also use a third-level (sub)domain for the service. In other words, if your domain is example.com, we can make the platform available at an address such as 360.example.com — where "360" can be replaced with any word you choose.

We can provide a server hosted in Germany or Finland — depending on your preference.
All servers are connected to the internet via a 1 Gbit/s link, ensuring fast and stable data transfer even for the largest point cloud projects.

Yes — as part of a dedicated server plan, we can install and configure Nextcloud for you. This will allow you to use the server as a private file hosting and sharing solution.

Please note: we perform the initial setup; ongoing administration and management of the file storage system (for example, users, permissions, backups) will be your responsibility.

Yes. Any project can be downloaded as a single archive containing all its data and the viewers for virtual tours, point clouds, meshes, IFC/Revit models, 3D Gaussian splats, PDFs, 360° videos, and maps. You start the download in the project settings and receive an email with the link as soon as the archive is ready. You can also request one archive with all of your projects at once.

A browser cannot open such an archive by simply double-clicking a file because the viewers load their data through requests that browsers block when files are opened locally. That is why the archive includes a small web server: ready-made applications for Windows and macOS, plus the same server as a Python script for anyone who prefers to run the source code. The included README.txt describes all three options step by step, including how to allow the macOS application to run — it is not signed with an Apple developer certificate.

Once the server is running, the project opens in your web browser at a local address and works exactly as it does online — with no internet connection at all. This is ideal for a construction site without internet access, a presentation on a laptop, or delivering a project on a USB stick or network drive.

The archive is a plain static website, so you can also host it yourself and share it with your clients. The only requirement is that it must be served from the root of a domain or subdomain (for example, tour.your-company.com) because the pages reference their files by absolute paths.

When you start the download, you also choose how long the link remains active. By default, the archive is automatically deleted after 24 hours. Alternatively, you can request a permanent link, which remains available until you delete the archive or the project. The link does not require a password — anyone with access to the project can use it to download the archive. Until it is deleted, the archive counts toward the project size.

Offline projects are available with paid plans — the plan comparison table shows exactly which ones include them.

Yes — we offer a self-hosted version of the software for complete offline use, ideal for organizations that need to keep sensitive data in-house.

The self-hosted version is available for a one-time payment of €4,500. You will receive a Docker container with complete setup instructions and guidance for the initial deployment on your own server.

The container comes with lifetime usage rights and includes one year of access to updates. After one year, you may continue using the container with its current features or purchase an extended support package to receive future updates.

Alternatively, dedicated server plans are available and include unlimited access to all features. Storage can be expanded up to 308 TB.

Requirements depend largely on the size of your point clouds. If you work with 10-20 million points per setup, we recommend the following:

• At least 64 GB of RAM, plus a large swap file as a fallback.
• A fast SSD or NVMe drive for the container itself — project storage can be placed on a regular HDD.
• CPU performance is not critical; a dedicated GPU is not required.
• SMTP access to your mail server is required to send emails from the system.
• You must configure external internet access, including a domain, DNS, an SSL certificate, and a reverse proxy — this is standard if you already have a managed server.
• You will also be responsible for creating backups.
• No database maintenance is required — everything is managed automatically inside the container.

When these components are in place, the platform will operate reliably and efficiently on your infrastructure.

Yes. Besides Google and Microsoft Entra ID, the platform can sign users in through any standard OpenID Connect (OIDC) provider — including Active Directory Federation Services (AD FS), Okta, Keycloak, and Auth0 — so you can keep using your existing IAM procedures. Accounts are provisioned automatically on first sign-in and matched by email address. Configuration requires only a discovery URL, client ID, and secret, which are set in the admin settings.

Yes — customization is available. Please contact our support team and specify what you would like to change — the visual theme, email templates, or other elements. We will discuss available options and help tailor the system to your needs.

Yes — if you use a dedicated server, your IT team can customize many parts of the user interface to reflect your company's branding.

The system uses Jinja2 templates for web pages and emails, and CSS stylesheets for styling. This lets you modify visual elements such as logos, colors, layouts, and wording.

If needed, we are always available to help with customizations, though your team can implement most changes independently.