> ## Documentation Index > Fetch the complete documentation index at: https://docs.prodexlabs.com/llms.txt > Use this file to discover all available pages before exploring further. # Factory Management > Create, organize, version, share, and delete the factories in your workspace. ## Overview Factories are the self-contained workspaces where everything you build in ProDex lives — simulation models, entities, data pipelines, BOMs, plans, and results. [Dexter](/product/dexter/chat-and-tasks) is factory-scoped too: each factory has its own conversations, [knowledge base](/product/dexter/memories), uploaded files, and [custom workflows](/product/dexter/custom-workflows), so context built in one factory doesn't leak into another. Everything in a factory saves continuously as you work — there is no manual save step. For the conceptual background, see [Key Concepts](/getting-started/key-concepts). ProDex runs in all major desktop browsers. There is no mobile app or mobile browser support — plan on a desktop for both building and reviewing. ## What's Inside a Factory | Category | Contents | | -------------- | ---------------------------------------------------------------------------------------------------------------------------- | | **Simulation** | Models, snapshots, schedules, entities, constants, lookup tables, runs, experiments, Monte Carlo runs, KPI and chart queries | | **Data** | Pipelines, insights | | **Supply** | BOMs, configuration templates, configurations, configuration revisions | | **Planning** | Planning models, planning runs, demand and supply orders (when planning is enabled for your account) | | **Dexter** | Conversation history, knowledge base, uploaded files, reports, scheduled jobs, custom workflows | Switching factories switches all of it at once — models, pipelines, plans, results, and Dexter's context all follow the active factory. ## The Factory Selector Click the **factory name at the top of the sidebar** to open the factory selector: * **Search factories**: filter the list by name * **Current**: the factory you're in now * **All factories**: every factory you own, listed alphabetically * **Star**: mark factories as favorites to find them quickly * **Footer actions**: **New Factory**, **Factory files** (import/export), **Sharing**, and **Factory settings** ## Creating a Factory From the factory selector, click **New Factory**, enter a name, optionally add a description, and create it. The new factory opens immediately with an empty workspace. Name factories for the facility or scenario they represent: "Building 7: Current State" stays findable in a long list; "Test Factory 3" doesn't. ## Renaming and Describing a Factory Open the factory selector and click **Factory settings**. The **General** section holds the factory's **Name** and **Description** — edit either and click **Save**. You can also just ask Dexter: *"Rename this factory to Building 7: Proposed Layout."* ## Version History Because ProDex saves continuously (there's no manual save), it keeps **every** version of a factory, not just the latest. Each edit you make, each [Dexter](/product/dexter/chat-and-tasks) turn, and each automatic checkpoint is preserved as a point-in-time version you can return to — you never have to remember to snapshot before making a change. To browse them, open **Factory settings → Version history** (under **Data**) and click **Open**. This opens the version tree: a timestamped list of every previous version of the whole factory. Select one to inspect it, then **Roll back** to restore the factory to that state. Rolling back first snapshots your current state, so the rollback itself is reversible if you change your mind. Version history travels with a [shared factory](#sharing-a-factory-with-teammates): a recipient can move back through previous versions too, including versions authored by other members of the share. Version history is the built-in safety net before risky structural changes. For a portable backup you control as a file, use [Export](/product/factory-export) as well. ## Deleting a Factory Open **Factory settings** and use **Delete factory** at the bottom. **Deleting a factory is permanent.** As the dialog itself puts it, deleting removes the factory "and all of its models, schedules, and runs" — along with its pipelines, BOMs, plans, and Dexter context. This cannot be undone, so [export the factory](/product/factory-export) first if you might need it again. ## Sharing a Factory With Teammates Factories are scoped to the user who created them — teammates don't see your factories by default. The **Sharing** menu in the factory selector has two actions: **Share factory** and **Publish Update**. ### Share Factory **Share factory** opens a dialog listing the users in your organization. Select one or more recipients and click **Send**. Each recipient gets a notification and must **accept** the share; once accepted, they receive their own copy of the factory. **Sharing creates an independent copy — it is not live co-editing.** Think of it like a branch: after the recipient accepts, their copy and your original evolve separately. Changes they make never flow back to you, and changes you make don't appear in their copy automatically. ### Publish Update Your factory is already saving a new [version](#version-history) constantly as you work, so **Publish Update** isn't what *creates* a version — it's what **notifies** your collaborators that there's a new one worth picking up. When you've made changes worth distributing, **Publish Update** sends the current version of your factory "to everyone with an accepted shared copy," together with an update note that recipients see in their notifications. Each recipient then chooses whether to apply it: applying moves their copy to your published version (their current state is snapshotted first, so they can back out). Nothing reaches a shared copy until you publish, and nothing changes in it until the recipient applies — so a published update is the deliberate, owner-initiated way to move a shared factory forward. ### Share Notifications The **Notifications** inbox at the bottom of the sidebar tracks the sharing lifecycle: shares waiting for you to accept, confirmations when a recipient accepts your share, and notes from published updates. If several people need to work toward one factory, the working pattern is: one owner shares copies, collaborators build on their copies, and an admin can later [merge factories](/product/team-management#merge-factories) into a consolidated result. ## Export and Import The **Factory files** menu in the factory selector holds **Export Factory** and **Import Factory**. Export downloads the factory as a portable `.prdx` file; import creates a new factory from one. This is the path for backups, moving work between environments, and sharing across organizations — see [Export & Import](/product/factory-export) for the full details. ## Factory Scope and Isolation | Scope | What lives here | | ------------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Factory** (per-user) | Models, entities, BOMs, pipelines, plans, results, Dexter conversations, knowledge base, uploaded files, workflows | | **Organization** (shared) | Team roster and roles, [organization memories](/product/dexter/organization-memories), integration documentation | Day-to-day work in a factory is visible only to its owner (and to whoever they've shared a copy with). Admins additionally see every factory's name and owner on the [Admin Panel](/product/team-management), where they can merge factories across owners. ## Best Practices * **One factory per scenario or facility.** Keep the current state in one factory and proposed changes in another; compare by switching rather than tangling both into one model. * **Export before destructive changes.** Version history can restore you, but a `.prdx` export is a backup you hold in hand. * **Publish updates deliberately.** Batch your changes and attach a meaningful update note — recipients see that note in their inbox. * **Prune old factories.** Favorites float the important ones; delete the rest to keep the selector short.