> For the complete documentation index, see [llms.txt](https://help.resouris.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.resouris.com/start-here/quick-start.md). # Quick start **Audience:** a fresh roster-area admin on a working ReSouris install. 15 minutes end-to-end. ReSouris is a [resource management platform](/how-it-works/resource-management-model.md) — this walk-through gets you from "signed in" to "published roster" by touring each of the five resource classes (people, rooms, equipment, service lines, allocation policy) before invoking the solver. **Prerequisites:** * A licence is installed. If not, see [Install a licence](/part-2-running-resouris/install-a-licence.md) first. * You have at least one staff record and one service line — either seeded by your install or created manually. * You hold `roster.generate` and `roster.publish`. ⛔ These are held by `rostering_manager` **only** — not by `tenant_admin`, however broad that role otherwise is. See [Roles and access](/part-2-running-resouris/permissions.md). ## 1. Sign in Visit `/ui/sign-in` and sign in via your organisation's SSO provider. You land on the Dashboard. ## 2. Look at About Visit `/ui/admin/about`. Confirm: * **Tenant identity** — UUID + slug + display name are what you expect. * **Deployment mode** — SaaS / self-hosted / air-gapped. * **Licence status** — green if the currently-active licence is within its validity window. * **Corpus version** — should be `v1.1` for a current install. Copy your tenant UUID with the one-click copy button. You'll need it if you open a support ticket. ## 3. Explore Staff (resource class: **people**) Sidebar → **People management** → **Staff admin**. You see the staff list scoped to your roster area(s). This is the primary resource catalogue — every worker's identity, competencies, working pattern, and lifecycle events live here. Click one staff record. The edit page has \~16 tabs. The ones that matter for roster generation: * **Identity** — display name, employment status, department. * **Working pattern** — contracted hours, days-off pattern, part-time / full-time. * **Competencies** — what activities they are credentialled to do. * **Job plans** (if any) — activity-level entitlements (e.g. "12 CT-Abdomen sessions per 13-week period"). * **Training plans** (if any) — development goals with signoff pathway. You do not need to author anything here on first pass. Just skim so you know what the solver is working with. ## 4. Look at Service lines (resource class: **competencies + demand shape**) Sidebar → **Organisation** → **Services**. Each row is a workstream your staff produce work into — the demand-half of the model. Service lines define what needs to happen, in which rooms, with which required competencies, at what priority. Click one to open its edit page. Key fields: * **Priority** — solver uses this as the lex-priority weight (higher first). * **Target roster tier** — the seniority band expected. * **Activities** — the list of things this service line produces (each with a `splittable` flag per the split-shifts phase). * **Rooms** — via patterns (day-of-week × sub-slot) and per-date overrides. * **`allow_split_shifts`** + **`handover_minutes`** — opt-in to sub-window sub-assignment per the v1.6.2 phase. Again, skim only. You'll iterate on service-line configuration once you've seen the solver's output. ## 5. Trigger a roster generation Sidebar → **Scheduling** → **Auto-roster**, then generate. Pick: * **Roster area** — the department or areas you want to roster. * **Horizon** — how many weeks forward. * **Allocation policy** — must already be `active` (see below if none exists). Click **Generate**. The job enters the roster-generation queue and runs asynchronously. Progress shows on `/ui/admin/auto-roster`. Typical solve time: 30 seconds to 5 minutes for a single-department horizon; longer for large multi-department horizons. **If no allocation policy exists:** go to `/ui/admin/allocation-policies` (sidebar → **Fairness & cover**), create one, pick a preset, save, then publish. See [Author an allocation policy](/set-up-what-you-schedule/author-an-allocation-policy.md) for the details. ## 6. Review the candidate roster When the job finishes, click through to the roster view. You see the grid: sub-slots on X, staff on Y (or roster areas, depending on view mode). Each assignment cell has a hover-tooltip showing: * activity + room, * the score components the solver used to pick this staff for this slot (priority + mandatory-bonus + competency-value + equity-deficit + entitlement-debt), * the audit-event ID that recorded the decision. Spot-check a few cells. If the choices look reasonable, proceed. If not, adjust the allocation policy weights and regenerate. ## 7. Publish Click **Publish** on the roster job page. The candidate assignments become the active roster. Notifications dispatch to affected workers (email + push where configured). Post-publish sickness or leave triggers reschedule proposals — see [Sickness and leave](/how-it-works/sickness-and-leave.md). ## 8. Check the audit chain Sidebar → **Operate** → **Audit**. Filter by: * **Days** — 7 / 30 / 90 / 365 preset. * **Chain status** — `intact_only` should show green across the board. * **Alerted** — should be empty. Every action you just took (sign-in, roster generation, publish, notification dispatch) appears as an audit event with a hash-chain link to the previous event. ## What comes next * Customise the allocation policy → [Author an allocation policy](/set-up-what-you-schedule/author-an-allocation-policy.md). * Handle a multi-staff sickness event → [Report a sickness batch](/run-the-roster/report-a-sickness-batch.md). * Understand why a specific person got a specific slot → [Equity and fairness model](/how-it-works/equity-model.md). --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.resouris.com/start-here/quick-start.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.