Forward Compatibility Policy

At coolOrange, we believe that software should empower, not restrict engineering teams. Our forward compatibility policy provides the clarity and confidence needed to maintain and upgrade your customizations with minimal disruption. 

Why cmdlets? 

We take a deliberate and customer-centered approach to software customization: 

• Software should adapt to customer workflows, not the other way around. 
• Customizations should be accessible, even to users with minimal coding experience. 
• Scripts should be fully accessible and modifiable, enabling flexibility and independence. 

That’s why we developed a comprehensive set of PowerShell cmdlets that wrap the most common Autodesk Vault APIs. By building your customizations on top of these cmdlets: 

• You avoid direct dependencies on Autodesk’s API changes. 
• You benefit from quick adapatations and enhancements through simplified scripting, public documentation, and transparency. 
• You gain compatibility across major and minor Autodesk Vault versions with minimal maintenance effort. 

We commit to releasing a compatible version of our software within 6 weeks of Autodesk’s annual Vault release, except in rare cases of major platform changes (e.g., the transition from .NET Framework to .NET Core). This approach enables faster adoption of new Autodesk technology without the traditional risks or delays. 

Our goal is to eliminate fear around customizations, reduce upgrade costs, avoid vendor lock-in, and give our customers a secure, flexible, and maintainable path forward. 

Compatibility Scope 

✅ Fully Covered: Scripts using only coolOrange cmdlets 

• Forward compatibility is guaranteed across Vault upgrades and updates. 
• If a script breaks due to a change in coolOrange behavior, we fix it for free. 
• Breaking changes are rare and typically involve syntax (e.g., renamed switches, type changes). When they do occur, we provide corrections at no cost. 

⚠️ Partially Covered: Scripts mixing cmdlets and native APIs 

• The cmdlet logic is covered and maintained by us. 
• Native API parts (e.g., direct Vault/Inventor SDK calls) are not protected from Autodesk changes. 
• If affected by an upgrade, these parts must be manually updated and hence work is chargeable. 

❌ Not Covered: Fully custom .NET implementations 

• Custom add-ins for Vault, Inventor, Office, or the like, written entirely using native APIs, are outside the scope of our compatibility policy. 
• Although the code is provided, a professional developer is required to carry out the upgrade 
• These implementations are generally impacted by Vault upgrades and will require chargeable adjustments. 

Upgrade Timing Recommendation 

To ensure upgrade reliability and avoid ambiguity during testing, do not introduce new customizations during the upgrade process. Instead: 

• Complete customizations at least 6 weeks before the upgrade, or 
• Wait until 6 weeks after the upgrade is complete. 

Performing both at the same time makes it difficult to isolate whether a problem is due to the upgrade or to new changes, and significantly increases the effort required to troubleshoot issues. 

Free Risk Assessment

If you're unsure whether your scripts rely on unsupported native APIs or fall within our compatibility guarantee, we offer a free risk assessment. 

Our team will review your scripts and identify any components that might be affected by an upgrade. This service helps you understand risks upfront and plan accordingly. 

Upgrade Execution Options 

We provide three upgrade models to suit your preferred level of involvement and risk management: 

Like painting a room - You can do it yourself, do it with a coach, or hire a professional. In all three cases, you are the homeowner and must approve the final result. 

Testing and Final Acceptance 

Internally, we conduct thorough functional testing using our own test environments. 

In customer environments, we perform technical smoke tests: 

• We confirm that scripts load and run without errors. 
• We ensure all configured functions are present and executable. 

However, we do not validate: 

• Whether workflows behave as intended. 
• Whether the output is semantically correct or aligned with your internal business processes. 

Final validation and acceptance are always the responsibility of the customer, as only you can assess correctness based on your data, configuration, and business logic.