Library Browser › Working with Objects and Folders › Versions › Understanding Baselines

Understanding Baselines

The purpose of baselining an object is to lock a version.

Consider the case where you are editing some version of an automation object and saving the changes. After you complete all the planned changes, you baseline the current version of the object to prevent future changes to that version. You can check out a baseline version, modify it, and save the changes, but you cannot check in the object as the same version. You must check in the changes as a new version.

For example, assume you baseline version 0 of a process, then continue as follows:

1. You check out version 0.
2. You edit version 0.
3. You save version 0.
4. You check in version 0.
   • If you check in the changes as New Version, CA Process Automation creates the version successfully.
   • If you try to check in the changes as Same Version, the product displays the following message:

     You checked out a baseline version. To check in your changes, you must select New Version.
     

   You cannot overwrite a baseline version by checking in changes to the same version.

Consider baselining a version when you do not anticipate making more changes to the object. For example, it is good practice to baseline objects before you export them in a content package. You can equate the packaging process to a release process. So, before you release an object, you can lock it by selecting baseline at the final check-in. You can still modify the object later as long as you check in your changes to a different version.

Note: During an export of a folder as a content package, CA Process Automation exports Release Version attributes in nonmodifiable mode. The import process baselines all objects so that users in the target environment cannot modify the exported object versions.