packages allow you to choose entities individually and control options for how
to process associated entities during deployment. Custom deployment is
typically used for organizational entities, Functional Positions, Email
Templates, such as People, Queues, Roles, Organizational Units, Agents,
Services Items, Standards, Billing Rates, Account Definition, Agreement
Templates, Categories, and groups.
In the customer
deployment packages, you can choose to replace only certain attributes for a
service on the target site rather than replacing the complete service
definition . Under the
Deployment options , select the options that can be updated on the target
There are more
granular options controlling Service Items and Standards deployment behavior.
The Service Item instances and Standards entries can be optionally included as
a part of the deployment. But the option applies to all Service Item types and
Standard in the package. To include entries for some Standards or Service Items
but not the others, you will have to break them into separate packages.
During import, if the
Unit rate flag is set (Source XML) in
Definition, the 'Merge' option is selected for
Billing rates when creating the custom package in Catalog Deployer. If the rate
table already exists in target, the 'Merge' option will be ignored and behaves
as an 'Overwrite' by deleting the existing data records in the target.
validations should be in place for a Rate table which has 'Unit Rate' flag set.
This should also be implemented for Demand Mgmt, NSAPI and REX flows.
- Only one attribute should be
- Only one data record should
exist in the Rate table Data.
- The single billable
attribute must be of the data type 'Number' only (Integer/Long/Double/Money).
- If there are multiple
records in the data tab, do not allow the user to check 'Unit Rate' flag in the
via a custom deployment allows you to recreate all or part of the category
structure of the source site in the target site. Chosen categories and their
subcategories are deployed, and the relationship of the categories to services
with which they are associated is re-established to match that in the source
site. This supplements the capabilities provided by Basic deployment packages,
where only those categories associated with the services being deployed are
included in the package.
While deploying a
category on the target side, you can choose to :
- Not include the source side
association and retain only the target site entities.
- Or include the source side
association and merge/replace/skip the target associations in case the category
already exists on the target site.
A package may contain
more than one type of entity where there are interdependencies between the
entities. For example, a person must be associated with an existing
organization. Catalog Deployer automatically deploys entities in the correct
order, so these interdependencies may be maintained.
Further, there may be
interdependencies among entities of the same type: a person may designate
another person as a supervisor, or an organizational hierarchy may exist. In
these cases, Catalog Deployer also deploys entities in the correct order (the
supervisor entity first, for example) so the relationships may be
For each of the
entities (except functional positions) to be deployed, you have an option to
overwrite the entity definition at the target site with the new definition
contained in the package, or to skip the deployment.
deployment is risky since Catalog Deployer only checks for the existence of the
entity in the target site, and does not inspect its content (for example, to
see if the source is newer than the target). The Skip option can optimize
performance by not reinstalling entities that already exist, but should be used
in limited circumstances (for example, if you are deploying a large package for
the first time into a target site where the entities are not known to exist).
If any aspect of the deployment fails (for example, you attempt to deploy a
person whose home OU is not in the target site and not in the current
deployment package), you can fix the omission and redeploy the package. Only
package contents that still do not exist in the target site would be deployed.
For each entity type
(except email templates, functional positions, and agents), you also have the
option to specify the behavior of Catalog Deployer with regards to
re-establishing relationships to other related entities in the target site.
- Use “Do not include” to
deploy only changes to the entity definition, without attempting to duplicate
the relationships in the source site. This would be required if, for example,
you want to deploy a new organization only, and not the relationships of this
organization to numerous people, some of whom might not exist in the target
- Including source site
associations will typically be required. This will duplicate the relationships
in the source site at the target site. Using the “Skip” option will allow the
deployment to continue if some of the associated entities are not present in
the target site. For example, you may have assigned a queue to a service that
is still in development and has not yet been deployed. If you use the “Skip”
option, be sure to read the logs carefully, to ensure that no expected
associations have been skipped.
You can also merge
data imported from source site to target site during deployment. This option is
available for service item definitions, standard definitions, billing rate
definitions, and agreement templates.
Portal page and
portlet permissions can be deployed with roles. The deployment must be
performed after the portal pages and portlets have been imported through Portal