Environment Updates

The environment is your shared definition of what blocks on a P&ID represent — how valves, instruments, sources, and connectors should be recognized, how TAGs are built, what fluid behaviours apply. Environments evolve over time as teams refine their classification rules, add new valve types, or adjust TAG conventions.

AseptSoft keeps environments in sync across three locations: your local machine, the project folder (for team sharing via the portability workflow), and the AseptSoft cloud (for centralized, organization-wide distribution). Every time a newer version appears anywhere, you decide whether to accept it, ask first, or stay on your current version. Nothing is ever overwritten silently — every change creates a backup you can roll back to at any time.

📋 Opening Environment Update Options

From the AseptSoft ribbon, open Settings and find Environment Update Options. The window lets you control the update policy for each source and see the current status of every environment on your machine.

The window is divided into three sections:

1. Top left — From Project: Controls how updates arrive from your teammates via the project's portability folder.

2. Top right — From Cloud: Controls how updates arrive from the AseptSoft cloud.

3. Bottom — Environments table: Lists every environment on your machine with its local version, project version, cloud version, and status.

⚙️ Update Policies

For each source (Project and Cloud) you choose one of three policies. They work independently, so you can have auto-update from cloud but always-ask from project, for example.

💡 Missing environments are always downloaded, regardless of policy. If the cloud has an environment that doesn't exist on your machine at all, you get it on the next project open — no prompt, no policy check. This ensures new team members receive the full set automatically.

🔄 Auto-Update Notifications

When an environment updates automatically (and you haven't turned off notifications), a small card appears showing what changed.

The notification is non-blocking — it floats over AutoCAD but doesn't stop you from working. Click OK to dismiss, or Open Environment Options to review the change and optionally roll back.

💬 Always Ask Mode

When a source has a newer version and your policy is Always Ask, you see a prompt like this when the project opens.

📋 Each source asks at most once per project open to avoid dialog stacking.

📊 Reading the Environments Table

The table shows one row per environment. Each row gives you a complete picture of where things stand.

🖱️ Per-Row Actions

Update

Downloads the newest available version from the highest-version source (project or cloud, whichever is higher), backs up your current version first, and replaces the live file. This is the fastest way to bring an environment up to date without waiting for automatic sync.

Import from File

Replace an environment with a local .aseptsoftclassdb file from disk. Useful when:

• A colleague sends you an updated environment by email

• You received an environment from AseptSoft support for a customization

• You want to restore an environment from a manual backup

The imported file is assigned a version number one higher than any known source (local, project, or cloud), ensuring it takes precedence and doesn't get auto-overwritten.

Push to Cloud

Uploads your local environment to the AseptSoft cloud, making it available to everyone in your organization. This button only appears if you have the EnvironmentAdmin or OrgAdmin role for your organization — otherwise it's hidden.

When you push:

1. The local version is bumped above the cloud's current version (e.g., cloud is v5 → local gets v6).

2. The local .aseptsoftclassdb file is uploaded.

3. The manifest is regenerated with the new version and SHA-256 checksum.

4. The previous cloud version is automatically archived under history/ on the server with the filename v{version}.aseptsoftclassdb.

💡 Prepare for Portability automatically pushes all environments used by the project to the cloud as its final step (if you have the empowerment), so you rarely need to push manually.

Share Cloud Access

The Share Cloud Access button at the bottom of the window copies the direct download URL for the cloud installer (environments.exe) to your clipboard. Send this link to colleagues so they can install the same set of environments with a single click.

🕒 Backup History and Rollback

Every time an environment is overwritten — by auto-update, manual import, portability bump, or cloud push — the previous version is preserved with full metadata. Click the 🕒 history icon on any row to see the complete backup timeline.

Each entry shows:

Activating a Historical Version

Click Activate on any row to roll back to that backup. When you do:

1. The current live environment is backed up first (reason: replaced-by-historical-restore).

2. The selected historical version is copied to the live location.

3. The environment is marked as Detached (historical) in the main window.

A detached environment means you're intentionally running an older version. Automatic updates are paused for this environment until a genuinely newer version (higher than the one you were on when you detached) appears in a source. This prevents auto-updates from immediately re-overwriting your rollback.

Historical Version Reminder

If an environment is detached and a newer version is available, AseptSoft periodically reminds you once per day.

📁 Bootstrapping Missing Environments

If an environment exists in the cloud but is completely absent on your machine (for example, a new team member's first project open), AseptSoft downloads it automatically on project open — regardless of your update policy. This ensures everyone has the complete set of environments defined for the organization without any manual intervention.

Missing environments never prompt for confirmation, and they are never affected by Skip This Version or Update Manually Only settings. The goal is to guarantee a usable starting state.

🏭 Pharma Example: Jacobs Project Environment Lifecycle

Here is a typical lifecycle for an environment across a team at a pharmaceutical engineering company.

1. Initial setup: Maria, an EnvironmentAdmin at Jacobs Engineering, configures the classification rules for a customer's plant in the First Time Setup workflow, using the Classification Window. She ends up with a refined environment she calls JacobsPharmaV1.

2. First push: Maria runs Prepare for Portability. The environment bumps to v2, copies to the project folder, and is pushed to the cloud (since Maria is EnvironmentAdmin). The cloud now has v2.

3. Team bootstrap: James, a new team member, opens the project for the first time. His machine doesn't have JacobsPharmaV1 at all. On project open, it's automatically downloaded from the cloud. His local = v2, cloud = v2, no prompt.

4. Refinement: Maria improves the TAG localisation rules and runs Prepare for Portability again. Local bumps to v3, project bumps to v3, cloud bumps to v3. James's machine still has v2.

5. James's update: James opens the project. His policy is Auto Update (Recommended) for cloud. His v2 is backed up, cloud v3 is downloaded and applied, and a notification tells him the environment updated from v2 to v3.

6. Local customization: James wants to try a slightly different TAG rule experimentally, but not push it to the team. He modifies the environment locally — local stays at v3 but has different content. Next day, Maria pushes v4. James's policy normally auto-updates, but he wants to keep experimenting. He opens the Environment Update Options window, switches cloud policy to Always Ask, and on next open clicks Skip This Version on the v4 prompt.

7. Rollback: James's experiment doesn't work. In the Environment Update Options window, he opens the History for JacobsPharmaV1, finds the v3 backup from two days ago, and clicks Activate. His environment is now "Detached (historical)" at v3. Automatic updates are paused.

8. Reattach: A week later, Maria pushes v7 with a feature James wants. Next day he sees the daily reminder dialog showing "you are on v3, latest is v7". He clicks Reattach to Latest. His detached state is cleared, his historical v3 is backed up, and cloud v7 is downloaded.

🔄 How Environments Fit into the Portability Workflow

The Prepare for Portability command packages a project so teammates can open it on different machines. As part of this workflow:

1. Every environment used by the project is bumped to a new version.

2. Each environment is backed up under the reason pre-portability-bump.

3. The new version is copied to the project's _portability/Environments Update folder so teammates get it when they open the project.

4. If you have EnvironmentAdmin or OrgAdmin empowerment, the same version is also pushed to the cloud. All three locations (local, project, cloud) end up at the same version number.

The AutoCAD command line shows each step in detail, including which environments were processed, what versions they were bumped to, and whether the cloud push succeeded.

🔑 Who Can Push to the Cloud?

Pushing to the cloud requires special permission in the AseptSoft identity system. Two roles grant this:

If you try to open the Environment Update Options window and the push icon doesn't appear on any row, you don't have the empowerment. Ask your OrgAdmin to assign you the EnvironmentAdmin role for your organization. The push icon will appear the next time you open the window.

🔗 Related Pages

• First Time Setup — Classification and TAG recognition setup (Glass 1 configuration)

• File System — Where environments are stored on disk

• AseptSoft Project Workflow — Overall project workflow including portability