Configuration Guidelines > Creating and Modifying Objects >

Modifying Objects

There are many reasons to modify an existing object. For example:

New functionality is often added to core business components during a major release. Typically, this new functionality depends on the existence of new fields or joins that have been added to existing business components. During the upgrade process, these new fields or joins will only be added to the standard business components (identified by name) or to copies that are directly related to a standard object. This is why you must specify the Upgrade Ancestry property for any cloned business components, applets, integration objects or reports.

By specifying the Upgrade Ancestry property, you can be sure that, during the upgrade process, all of your cloned business components will match the standard business components that were used as the basis for the cloned object. This helps reduce any difficulties after the upgrade, which are inherently hard to resolve. Many of these errors occur because some C++ code from the specialized class for the business component or applet is set to a field that does not exist in your custom copy of the specialized business component or applet. The only way to resolve the error is to compare your custom business component with the standard business component and manually add any necessary new fields.

NOTE:  Clone an object only when you are customizing the application. Do not clone objects to maintain a pristine copy of the object definition. The Archive feature in Siebel Tools lets you archive one, multiple, or all objects within a project into an SIF file. You can reimport these archive files at any time, and by using a third-party source control program, you can use these archives to control the versions of your configuration changes.

Also, be aware of the following:

 Configuration Guidelines 
 Published: 18 April 2003