# Projects and environments (/docs/use/projects) A project is one community program, such as your launch campaign or your ambassador program. It holds the program's quests, points, rewards and members, and its app. Before you change anything in Console, check which project and environment you have selected in the header. ## Start in test [#start-in-test] Test and live keep separate project data. Development previews and new staging builds use test. Quests, their settings and other definitions change in test; in live, Console shows them read-only with **Edit in Test**. See [test and live](/docs/concepts/environments). > [!WARNING] Test is not a simulation > People still use real sign-in, and configured external services may receive real requests. Test is not a promise that every action is simulated. Try the experience yourself before moving it to live. Check: * The wording. * Sign-in. * The main thing members do. * The resulting progress. ## Work with your agent [#work-with-your-agent] Give the agent the project identifier and a description of the result you want. Let browser authorization handle credentials. The agent should report: * **A working URL.** * **The action it verified.** * **Anything still blocking launch.** Pick the guide that matches your code: - [Create a new app](/docs/start/new-app) — For a new app, start from the hosted starter. - [Connect an existing app](/docs/start/existing-app) — For an existing app, connect your repository. ## See how the project works [#see-how-the-project-works] Open **Project map** in Console to explain the project to a teammate, a reviewer, or a board. The map is drawn from what is published and configured in the selected environment: quests, collections, referral programs, point ledgers, leaderboards, trackers, pickup inventory, sign-in apps, and the Discord connection. It stays current without a separate document. | View | Shows | | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Builder** | Published quests in columns by the steps that unlock them, the trackers that start them, and your drafts beside them. See [Compose quests in the builder](#compose-quests-in-the-builder). | | **Interaction map** | How members sign in and reach each collection, which services report activity, what Domino checks and records, which quests unlock others, and the rewards, referrals, and standings each leads to. | | **User flow** | One quest or referral program from the first step to every reward, including linked accounts, prerequisites, review, budgets, retries, milestones, and merch handover. | | **Decision matrix** | Each condition a quest or referral program distinguishes, what the member sees, what happens as a result, and who owns the decision. | Select a step to open the quest or page behind it. Use **Copy as Mermaid** or **Copy as Markdown** to paste a view into a document or slides. The copied diagram keeps its styling. The map shows what the published definitions declare. It does not show the checks inside quest code. ### Compose quests in the builder [#compose-quests-in-the-builder] Sketch new quests in the **Builder** view, then hand them to a coding agent to add to your app. Nothing in it is published from Console, and a project with nothing published yet opens straight into it. 1. Add a quest from **Quest**, starting from a one-tap claim, a quiz, a photo, a link, tracked activity, or a staff confirmation. Add a **Tracker** for X posts, Discord messages, or records your server sends, and choose **Make it a campaign** to group the quests with a window and enrollment. 2. Fill in the quest's trigger, how it's checked, when it completes, any cap per member, its rewards, and the quests it unlocks after. Draft quests can unlock after published ones. **Member view** shows how an app could present the quest, and **Code** shows the file the builder writes. 3. Choose **Hand off to agent**. The request asks the agent to add the quests to the app, check them, and publish them to **Test**. Choose **Send to Build** to [review it in the playground](/docs/build/playground#send-a-request-from-another-page), or **Copy prompt** for your own agent. > [!DEV] > The builder writes each quest as a code file. The hand-off request lists the files and asks the agent to keep every key, add the quests to the app, check them with `domino deploy --preview`, and publish them to **Test**. A check the builder can't express, described under **Custom check, written by the agent**, reaches the agent as a `TODO(agent)` in the code. Drafts are saved in this browser for the project, until you remove them. Once the agent publishes the quests, the map shows the published quests in place of their drafts and offers to remove the drafts. On a narrow screen, the builder lists the quests by step instead of drawing the map. Select a published quest to see what it requires and rewards. A quest defined in code offers **Ask the agent to change it** or **Copy prompt**; a quest created in Quest Studio opens there with **Edit in Quest Studio**. ## Review changes [#review-changes] With the appropriate permissions, you can manage quests, review submissions, and configure project access in Console. Some settings belong to source code, while others can be customized in Console. > [!NOTE] Console customizations outlast code defaults > A custom value remains in effect when the default changes in code. Read [Manage quests](/docs/use/quests) before changing requirements or rewards for an active campaign. ## Give people access to a project [#give-people-access-to-a-project] Organization administrators can do everything in every project. Anyone else in your organization works only in the projects an administrator gives them access to, with the roles they choose. 1. Invite the person to your organization: open **Settings → Access → Team** and choose **Manage members**. 2. Under **Project permissions**, choose them as **Team member**. 3. Check their roles and the environments they work in. 4. Optionally, pick the day their access ends under **Access ends (UTC, optional)**. 5. Choose **Save project access**. | Role | Can | | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **Editor** | Publish quests, manage stock and points, send tracker records and enroll members from a backend | | **Reviewer** | Review evidence and retry attempts | | **Staff** | Confirm quests and hand over rewards | | **Viewer** | See the project's [dashboards](/docs/build/dashboards#share-dashboards-with-a-sponsor), and nothing else: no members, evidence, quests or settings | Editors, reviewers and staff also read the project: its members, quests, activity and analytics. Roles add up: a reviewer who is also staff can do both. Access ends at the end of the chosen day, UTC, without anyone removing it. The person stays listed under **Project permissions** with **Expired** and the day it ended, so you can still see who had access and until when. Edit them to give access again; clear the date to keep access until you change it. To remove access, clear all their roles. > [!NOTE] The viewer role and end dates are experimental > They can change in a minor release. > [!DEV] > `management.grants.set({ subject, roles, environments, expiresAt })` sets a person's access; `expiresAt` is epoch milliseconds, or null for no end. `grants.list()` lists every grant, ended ones included. A grant's `roles` lists only the roles SDK 1.x names, so a viewer's is empty; `projectRoles` lists every role. In `management.access()`, a project's `permissions` likewise leaves out `dashboards`, the viewer's only permission, which `projectPermissions` includes. `viewer`, `expiresAt`, `projectRoles`, `projectPermissions` and `dashboards` are experimental. Every change is recorded under **Access & API keys** in **Audit history**, with its end date. ## See who created a project [#see-who-created-a-project] Open **Settings → General → Project details**. **Created by** shows the creator's name, primary email, avatar, and user ID when available. Projects created before a creation record was stored show **Not recorded**. In **Audit history**, each recorded user appears with the same details. Deleted users and unavailable user lookups keep the recorded actor ID. Automated actors keep their identifiers. Organization admins can select **Access & API keys** to see project creation, name and slug changes, access changes, and personal key, service key and app login key changes across Test and Live. ## Rename a project or change its slug [#rename-a-project-or-change-its-slug] Organization admins can edit the name under **Settings → General → Project name**, then choose **Save**. Renaming keeps the project ID, slug, and app address. To change the slug, choose **Change slug** under **Project slug** on the same page. Enter an available slug with 3 to 35 lowercase letters, numbers, and single hyphens between words. Type the current project name to confirm. Domino reserves some names, such as `console`, `api`, and well-known brand names; a reserved slug is refused with **Project slug is reserved**. Reserved names match exactly, so `console-tools` is still available. If your organization owns a reserved name, ask Domino support to release it to your project. Both changes apply to Test and Live and appear in **Access & API keys** history. > [!WARNING] A slug change changes the hosted test app address > Links containing the old slug stop working. Browser sessions at the old address do not carry over. Update bookmarks and any provider URLs that use the old address, and reopen development previews. Previous slugs stay reserved to this project until it is permanently deleted, so you can change back. If preparing the new address fails, the old address keeps working; retry the same change. The candidate slug stays reserved to your project. > [!DEV] > Project settings edits require an organization admin's Console session. CLI sessions and API keys cannot edit them. ## Delete or move a project [#delete-or-move-a-project] Organization administrators find **Transfer project** and **Delete project** at the bottom of **Settings → General**. Each opens a dialog that asks you to type the project's name to confirm, and each affects test and live together. | Action | What happens | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Delete project** | The project, its app and its keys stop working at once, and Console opens your remaining projects. Domino support can restore it for 30 days. After that its data, hosted app, repository and uploaded photos are erased. | | **Transfer project** | The project moves to another organization you also administer: its members, quests, rewards, integrations, keys and app. The app keeps its address. Past audit history stays with the old organization. | > [!CAUTION] Deleting cannot be undone from Console > Contact Domino support within 30 days to restore a deleted project. After that it is gone. Members belong to the project, so they move with it, with their identities, progress and rewards. A project's paid plan follows these too, where plans apply: * **Delete**: the subscription stops renewing and ends with the period already paid. If support restores the project before then, it carries on as before. * **Transfer**: the project keeps its plan until the period the old organization paid for ends, and that organization isn't charged again. To keep the plan, subscribe the project in its new organization from **Settings → Plan & usage**; nothing is charged before the old period ends. * **Permanent deletion**: the subscription ends at once. > [!DEV] > After a move, the Domino CLI notices that the project now lives elsewhere. In a terminal it offers to switch the checkout to the new organization and signs you in there. In scripts, run `domino login --organization ` once. ## Free projects [#free-projects] Where plans apply, an organization can hold up to 10 projects on the Free plan. Deleted projects don't count, and neither do projects on a plan, on their live trial or in its grace period. Every new project starts on Free, so when the organization already holds 10, Console says there's no room for another Free project. Moving a Free project into an organization that already holds 10 fails the same way; a project on a plan can always move. To make room, [delete a project](#delete-or-move-a-project) you no longer need, or put one on a plan. > [!DEV] > Creating or transferring past the limit fails with `limit-reached` (403, `limit: "free-projects"`).