Transport of IT Shop approval workflows and policies

Thanks for the reply Barry.

So I've tried both methods and both methods end up with an error regarding a dependency on Business Role class or Org Root.  The workflow contains many approval steps that refer to users that belong to Business Roles under a Business Role class.  I manually created these roles and class in the other environment to see if that would fix the issue, but it does not.  It seems that it is looking specifically for the OrgRoot UID, which doesn't make sense because of course they would be different in the two environments.  Is there something I'm missing?

Screen shots of using the Data Transporter Tool:

Transport through change label:

Error:

Obviously the workflow contains steps with a relation to Orgs (business roles) - for example „OR“ (Members of a certain role) or “OM” (Manager of a specific role).

The screenshot shows that the related Orgs have been exported too.

But these orgs are linked to an OrgRoot (Role class) which is not contained in the Transport.

And this OrgRoot ("Job roles") doesn’t exist in the target database.
Or: The OrgRoot exists there but with a different UID.

We have defined in the default which dependend objects will be exported automatically.

Not all dependencies are affected, it would be too much.

 And the OrgRoot of an Org is NOT marked to be exported automatically, that's why it was not added to the Transport.

Solution:

Transport the OrgRoot with an extra Transport before.
Or if the OrgRoot already exists with a different UID: Change the UID. The same objects must have the same UID in every OneIM database.
For that purpose I can provide a SQL script.

Following you can import the decision workflow.

Here it is.

-- Replace the UID of an OrgRoot

declare @UID_Old varchar(36) = '650027C4-A804-4A30-B8DE-20ECD2A9EA5B'
declare @UID_New varchar(36) = '1ca216dc-3cf2-4926-9ff5-a545e07a326e'

-- Create a new OrgRoot with the new UID
insert into OrgRoot
select @UID_New, --new UID
UID_OrgAttestator, Description, IsTopDown, XDateInserted, XDateUpdated, XUserInserted, XUserUpdated,
Ident_OrgRoot, XTouched, '<Key><T>OrgRoot</T><P>' + @UID_New + '</P></Key>',
IsDelegable, XMarkedForDeletion, UID_OrgType
from OrgRoot
where UID_OrgRoot = @UID_Old


-- Switch the child objects to the new OrgRoot
/*
-- will be done by the DB trigger
update OrgRootAssign
set UID_OrgRoot = @UID_New
where UID_OrgRoot = @UID_Old
*/

-- update OrgRootAssign based on the old settings
update OrgRootAssign
set IsAssignmentAllowed = o.IsAssignmentAllowed, IsDirectAssignmentAllowed = o.IsDirectAssignmentAllowed
from OrgRootAssign
join OrgRootAssign o
	on	OrgRootAssign.UID_OrgRoot = @UID_New
	and o.UID_OrgRoot = @UID_Old
	and OrgRootAssign.UID_BaseTreeAssign = o.UID_BaseTreeAssign



-- disable the trigger, it would disallow the change of the UID_OrgRoot
exec QBM_PTriggerDisable 'BaseTree', 'QER_TUBaseTree'

update BaseTree
set UID_OrgRoot = @UID_New
where UID_OrgRoot = @UID_Old

exec QBM_PTriggerEnable 'BaseTree', 'QER_TUBaseTree'

-- delete the old OrgRoot
delete OrgRoot
where UID_OrgRoot = @UID_Old

The same was used by Barry.

And he told me that it worked properly.

In the top of the script you have to define 2 variables with the old and the new UID.

Steffen