Certain objects have certain dependencies which you should take note of:
Committing a new User: In the current version, Ooyala Flex requires that an account and role are created before a new user is committed. This should be done in two/three different change requests:
First change request: is to create and progress an account from your source environment to your target environment. This will include the default role as part of account creation.
The second change request: is to create and progress new roles from your source environment to your target environment, if there are any being referenced by new users. (This is optional).
The third change request: is to create and progress new users from your source environment to your target environment.
User Passwords: If you transfer a new user from your source environment to the target environment, the new user will not be able to login via the UI, until the masteruser has reset that particular user’s password.
Note: The password will not be moved over with the user, so the masteruser must reset the password for that user, once it has been moved over to the target environment.
Note: The password for a user can be reset, by going to the details section for that particular user, and clicking the Reset Password link, located in the top-left corner. An email is then sent to that user, requesting that they change their password.
Configuration Manager can’t be used with mappers to create new objects in same environment in a different account. For example: if you have account A in source environment you will not be able to move all objects from account A to account B if the target environment is same as the source environment.
If the visibility of an object is updated at the master user level, to add a master account, that particular item will not be able to progress using Configuration Manager or the REST API.
If you want to create a new account in an environment via Configuration Manager, e.g moving an account from your source environment to the target environment, the account in the source needs to be enabled, so that you can apply the information from the account to the target environment, such as an accounts default role.
If you try to transfer an event or a workflow definition from the source environment to the target environment without configuring the filter/config or structure, then it cannot be enabled.
Workaround for this problem:
First create a change request in order to deploy the account. A warning will be shown, that informs you the metadata definition can’t be referenced to create the variant.
Open a new Change Request in order to deploy the metadata definition.
Finally create a new change request to update the same account. This will create a variant using the already deployed metadata definition from the change request in step two.