> For the complete documentation index, see [llms.txt](https://docs.geodin.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.geodin.com/administration/users-and-roles.md). # Users and Roles GeoDin includes an optional built-in user management system, runs on Windows-login authentication, and uses two licensing systems (a hardware-bound seat model for GeoDin and a separate key-based seat model for Onsite). This page covers user accounts, the single-ownership model that governs Onsite forms, licensing, and team-scope behaviour for custom content. For specific access-control topics, see also: * [Groups and Permissions](/administration/groups-and-permissions.md) * [Database Visibility](/administration/database-visibility.md) * [Multi-User Collaboration](/administration/multi-user-collaboration.md) * [Data Privacy and Ownership](/administration/data-privacy-and-ownership.md) ## Built-in user management system GeoDin includes a built-in user management system. It is **optional** - most customers do not turn it on. Where it is used, it is typically by organizations with strict access requirements (e.g. public authorities running \~20 users on the same database). Users are created with a name and a login credential tied to the Windows login used at machine startup. Apart from the optional web login described below, there is no separate password store and no SSO/MFA/directory-service integration documented in the product. Users and groups are maintained in the **User settings** method. Use the **Add new element** button to define a user: the user name is the workstation login, which can then be used for example to open a system database. The same button creates a group - name the group first, then add users to it. A web login can optionally be allowed. Select or clear the corresponding check box to activate or deactivate the function; when it is active, a separate user name and password can be set for that login. GeoDin Onsite has **no user accounts and no authentication** - it is a single-user desktop/tablet application. User name and computer name are captured passively in each form's `history` section for audit purposes. ## Authentication and environment constraints * Authentication piggybacks on the Windows login. * The installation scope (`All users` vs. `Local user`) is the only user-scoping decision for Onsite - it controls whether the executable is available to all Windows accounts or only the installing user. * GeoDin can run in a locked-down corporate environment with no internet access. Runtime telemetry and file transfer from GeoDin staff into the customer network are blocked in such setups. ## Single-ownership model (Onsite "one piece of paper") Onsite treats every form as **one piece of paper**: at any moment exactly one location owns the live copy. This model drives the Publish / Retrieve / Revoke workflow and prevents two field users from editing the same form in parallel. ### Two shelves on the shared delivery folder * **Incomplete** - any user with access can retrieve a form back from this shelf. * **Final / Complete** - once a form lands here, the original user cannot retrieve it. The form belongs to office staff. ### Publish behaviour * Publishing as **Complete** requires full form validation to pass; the deliverable bundle (`.GDOF`, PDF, GeoDinML, AGS) is generated. * Publishing as **Incomplete** is allowed with validation errors; only the `.GDOF` is shelved (no PDF or GeoDinML yet). * On publish, the `.GDOF` is moved to the shared delivery folder and the original file leaves the local `projects` folder - `Load local` will no longer find it. A local **photocopy** is kept on the device for disaster recovery. ### Retrieve and Revoke * **Retrieve** is the reverse of Publish: it reads a form back from the shared delivery folder onto the tablet and transfers ownership to the local user. After Retrieve, a photocopy remains on the shelf marked as not-owned. * **Revoke** reactivates a published-as-Complete form from the local photocopy. Use it when a publish was a mistake. Revoke is dangerous because it can overwrite data already processed downstream. The intended workflow is fire-and-forget: field users publish from the tablet, the form disappears locally, and office staff pick it up - a clean separation between field and office work. *** ## GeoDin licensing Two license types exist (Standard and Professional). With a Professional license, the **number of seats** determines how many users can run GeoDin simultaneously - for example, 3 seats means up to 3 concurrent users out of a 15-person team. * Any machine on the network can act as the license server. There is no separate license server product. * Licenses are **hardware-bound**. Hardware changes (new laptop, Windows 10 -> 11 upgrade) require reactivation by GeoDin support. * An **educational package** is available for colleges and students. * Civil 3D plugin (GeoDin Ground) users do not need a GeoDin license. Only people who manage and curate the database need paid licenses. * **GeoDin Onsite is licensed separately** and is not included with a GeoDin license. It uses its own seat-based licensing system - see [GeoDin Onsite licensing](#geodin-onsite-licensing) below. * Bundled Onsite licensing is available for contractors - contact GeoDin sales for details. For pricing details, see [geodin.com/pricing](https://geodin.com/pricing). ## GeoDin Onsite licensing Onsite uses a separate seat-based licensing system delivered via license key. A single key can cover multiple seats. * **Hardware binding:** each activation is bound to a machine. If the disk or memory is swapped, the license becomes unlinked - contact GeoDin support to re-activate it. * **Offline mode:** Onsite normally validates its license on startup. With no internet (e.g. tablet in the field), it falls back to offline mode for up to 30 days; after 30 days the license must re-validate online. * **License Manager UI** displays: key, license name (customer name), expiry date, maximum GeoDin version, offline grace period, multi-seat count, machine name, and hardware ID. Available in English and German. * **Onboarding:** post-purchase the customer receives an installer URL and a license key. First launch runs the License Wizard, which binds the license to the machine hardware ID. ## Dictionaries, custom content, and team scope Custom dictionaries, custom tables, and configuration settings are stored in the user's `syslib` folder. * **Dictionaries** are shared across all users who share the same GeoDin library installation. * **Custom test tables** can be local to a single user, or added to the general library and shared across the distribution. * When a user **edits a dictionary**, GeoDin records a timestamp and the dictionary becomes "frozen" - GeoDin distribution updates will no longer overwrite it, preserving the user's changes. * When sending data to an **external client** who does not have the same custom dictionaries, the sender must also ship the relevant `.GSD` dictionary files (or the full `syslib` folder). * **Risk profile:** low-risk dictionaries (client list, lab names) can be edited freely. Higher-risk dictionaries (soil types, fill patterns) should be edited carefully because losing future distribution updates can matter. * **Custom data types and layouts** also live in the `syslib` folder and must be manually copied between installations when a network install is not used. ## Trial and evaluation access GeoDin offers a **free 30-day trial** with no user limit; extensions are available on request. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.geodin.com/administration/users-and-roles.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.