FlexCM - Configuration Manager

This article explains how to work with Flex Configuration to pull configuration  from (source) Flex environment, store them locally or in git repositories and commit them to new (target) environments.

Introduction

flex-cm is a command line tool that allows you to pull configuration from (source) Flex environment, store them locally or in git repositories and commit them to new (target) environments.

flex-cm can be used to promote configuration across environments, create reusable configuration that can be deployed multiple times to different configurations, restore configuration to other environments, etc.

flex-cm is an operational tool and should be managed by Flex advanced users/system experts. flex-cm will help you promote configurations, however configurations should be designed and implemented ahead to allow this task.

Configuration Management definitions and concepts

• Flex environment: instance hosting a Flex Core installation
• flex-cm and Flex Core: flex-cm is a tool that uses Flex Core API to pull and commit
• flex-cm uses local filesystem to store configuration (flex-cm repository)
• flex-cm usually works with a source environment, where the configurations will be pulled from and/or target environment, where the configurations will be committed.
• Once the configurations are pulled into flex-cm repository, they can be reused in one or multiple environments
• flex-cm requires opening a session with ‘source’ and/or ‘target’ environment to define where configuration will be operated from/to
• flex-cm will prepare a “changerequest” with all configurations to be committed to the target environment. This ‘changerequest’ can be loaded and used lately, e.g., without accessing the source environment to promote configurations to the target environment.

Supported objects

Below is a summary of the objects supported

• action                        /actions 
• account                     /accounts 
• workflow_definition   /workflowDefinitions 
• resource                    /resources 
• task_definition           /taskDefinitions 
• wizard                        /wizards 
• metadata_definition   /metadataDefinitions 
• event_handler            /eventHandlers 
• message_template    /messageTemplates 
• profile                         /profiles 
• player_definition         /playerDefinitions 
• timed_action               /timedActions 
• account_property        /accountProperties 
• group                           /groups 
• workspace                   /workspaces 
• user                             /users 
• role                              /roles 
• taxonomy                    /taxonomies 
• tags                             /tags 
• tag_collections            /tagCollections
• user_defined_object_type    /userDefinedObjectTypes

Usually, configurations come together with other dependent relations. 

Configuration in Flex can get complex because:

1. The large number of dependencies 
2. Dependencies among configurations
3. Specific configuration parameter for each environment (e.g.: storage location...)
4. High level of flexibility to configure almost anything in Flex.

 Complex dependency graph example

flex-cm manages configurations only, it will not manage or promote running instance objects such as assets, workflows, or jobs.  

Quick walkthrough

flex-cm is delivered as a docker image. 

Note: Below quick steps assume you are working on a Linux environment.

Click here for a detailed Step by Step Guide for Using Flex CM

1. pull docker-image

docker pull registry.services.ooflex.net/flex/flex-cm

2. Create a directory where the flex-cm file configuration repositories will reside, e.g.: if storing in flexcm_repository

~/flexcm_repository/demo

3. Configure base setup, create a file in user home (Linux) `~/miocm-config.yml` with the following info 

defaultRepository: demo
defaultPath: /root/flexcm_repository

Notice: that `defaultPath` is usually fixed as it refers to the docker volume location

4. Start flex-cm, replace <your-user> below and try starting flex-cm  

docker run --rm  -v /home/<your-user>/miocmconfig.yml:/root/miocm-config.yml -v /home/<youruser>/flexcm_repository:/root/flexcm_repository -it registry.services.ooflex.net/flex/flex-cm  

5. Configure the source environment you are going to try first, e.g.: if you have not configured any environment replace your data below and run 

environment --envname <source> --endpoint https://<youraccount.domain>/api --username <username> --password <password> 

6. Run  

showrepos  
session
open --source <source_environment_name>
list --type actions

This should look like:

flex-cm definition and concepts

Flex Core support for Configuration Management

Flex-cm uses object UUID and revision to determine if an object exists in the environment and if this has been modified.

UUID

The UUID (Universally Unique Identifier) is a system defined read-only field. The UUID is generated upon an object's creation, and so, every object has a UUID.

• UUIDs are returned in the REST API as a JSON property and for existing objects.
• A UUID will be generated when an object is created and it is immutable.
• A UUID can be seen in the Dalet Flex Console, in the Object Details section for that object.
• A UUID will be returned in the configuration object REST API responses.
• A UUID will be used to uniquely identify an object in the REST API URL parameters.

Revision

A revision number will be generated when an object is created, and it will be updated when the configuration changes are saved.

Example: Any change to the name or description of an object is a new revision version.

The revision number can be viewed in the Dalet Flex UI, in the Object Details section for a specific object. The revision number will be in the following format:

• Number: is local to the environment and is a sequentially generated number (0, 1 ...N). This number represents the number of updates that have been committed for that specific object in this environment only. FlexCM manages revision changes across multiple environments and warns, as well as prevents committing configuration changes to target environments when the revisions do not match FlexCM central revision store. Dalet Flex updates the new revision codes for each configuration object. Then, it will maintain the revision code, recalculating it with every change that is made using the UI or FlexCM commit deployment.
• HashCode: is a unique 32 bit java hash for the object.

Flex configuration dependencies

Dependency management is critical when it comes to configuring Dalet Flex Environments. Some objects in your source environment might reference (and be Referenced by) other objects. When you try to promote configuration from one environment to another these dependencies should be configured otherwise promotion might fail. 

For example:

• Metadata Definition might reference objects (e.g.: Actions or User) which don’t exist on the target environment
• Workflow Definition might use Action which is using downstream Folder Resource, Storage Resource and Tags. These objects must be available either in the target environment or promoted together.

User Owner, Account and Visibility

Specific case of dependencies are Owners and Visibility of objects

• Owner includes user and account of the original configuration
• Visibility is defined at the object level

They should be resolvable on committing to the target environment, either because they exist (with same uuid, this is critical) or because the user/account/group are committed on same changerequest as other configurations. flex-cm provides several options to manage different scenarios of owner and visibility combinations.

Failing to have these dependencies already available or committed on the same flex-cm changerequest might lead to configuration partially deployed or not deployed at all.

flex-cm support for Configuration Management

flex-cm repository

The `miocm-config.yml` file defines the repository where the configuration will be used by flex-cm.

defaultRepository: demo
defaultPath: /root/flexcm_repository 

Reminder that `defaultPath` key is fixed here and it should be mapped on the docker image volume to the root folder where flex-cm will store repositories.

This flex-cm repository directory (e.g. demo) will contain:

• One folder for each environment which flex-cm has connected to pull or commit configuration. 
  • Any number of environment folders are possible here.
  • Tip: use ‘session’ flex-cm command to list environments.
• One folder for each flex-cm bundle with pulled out configurations (see below for flex-cm bundle features).
• A ‘CR’ folder with all internal information used by flex-cm (e.g. changerequest for each session opened).

flex-cm environment representation

Configuration inside the environments has a folder for each object type pulled out or ready to commit to the target environment.

Note: In above example “cmexamples” is defaultRepository and ‘source’ is the name of the source environment (could be any other thing, e.g. ‘stage’).

HINT: Use flex-cm command ‘info’ to list object types supported.

Additionally, each environment folder will have an `environment.yml` file inside. This `.yml` file will contain the information for that specific environment. The information in each `.yml` file can be altered at any time, simply by opening it in a text editor.

TIP: This is the `environment.yml` file created by the ‘environment’ flex-cm command.

e.g.:

endpoint: https://my-account.my-domain.com/api password: masteruser name: source 
uuid: 80f5dd1f-aa61-4973-b193-a07605c7870e username: mypassword 

Note: flex-cm bundle uses same object configuration structure, with no `environment.yml`, read more below.

flex-cm and Flex Core

flex-cm can be used in multiple scenarios or combination of operations, e.g.:

• Promoting from source to target environment (e.g. from stage to prod).
• pull (get) configuration from a source environment and store them in flex-cm repository.
  • Prepare locally in flex-cm repository the changerequest to apply on target.
  •  Committing the target.
• Using configuration taken from previous flex-cm repositories.
  • Load existing changerequest with configuration already ready to commit.
  • Commit to target.
• (new) Using flex-cm configuration prepared from flex-cm repositories.
  • Load existing flex-cm bundle.
  • Commit to target.

Reminder that on promoting configurations to target environment there are several requirements that need to be addressed:

• Owner and Visibility of object should be resolvable in the target environment
• Dependency of committed objects should be resolvable in the target env

Generally speaking, flex-cm requires the following steps to perform a promotion of configurations:

• Open a session to define source and/or target already defined environment in flex-cm.
• Use pull command to get configuration from source or target environment.
• Add or Update configurations from source to target environment.
  • This doesn’t access flex environments, it copies configuration across flex-cm environment directories.
  • All changes are capture by a changerequest which will be used later on the commit phase.
• Commit will send changerequest with the list of configuration and the operation to perform (add/update/delete configurations).
• • • This has 2 parts, flex-cm preparing configuration and changerquest to send to Flex Core via REST API
    • Flex Core processing the commit request
    • Flex Core will perform at this point:
      • Validation of the configuration received
      • Resolution of configuration, updating configuration to adapt to local target ids (e.g. setting local ids for user/visibility...)
      • Perform actual changes in a single transaction. Changes include adding/updating/removing configuration and trying to update enabled/started status for those configurations that support it (e.g.: storage resources)

             

 

 

Info and setup commands	Description
help	This shows you all the commands available in the system
version	Displays the shell version
exit, quit	Exits the shell
clear, cls	Clears the console
repository	Creates a new repository and config files
info	Shows all supported objects
showrepos	List all flex-cm repositories. Minimum one is mandatory.
environment	Create new environment
session	Add or update parameter driven current session

 

Operational commands	Description
open	Creates new flex-cm session to operate with source and/or target environment or open existing changerquest session
list	list configurations from a flex-environment
pull	Pulls (get) configurations from source or target envs.
add	This pushes new configurations to the target environment. This operation copies flex-cm local filesystem repository This pushes configurations which are different from source to the target environment. This operation copies flex-cm local filesystem repository
update	This pushes configurations which are different from source to the target environment. This operation copies flex-cm local filesystem repository This pushes configurations which are different from source to the target environment. This operation copies flex-cm local filesystem repository
remove	This remove configurations which are not in the source environment from the target environment. This operation deletes files flex-cm local filesystem repository only and prepares the changerequest.
commit	Commits the changes to git repository
dependencies	Pulls dependencies of object of passed UUID from the the given source or target environment
mapper	Mapper allows to re-map user, account and visibility from source (uuid objects) to target (uuid objects)
script	Parses the specified resource file and executes its flexcm commands
bundle	Load or create new flex-cm bundle in current open session. With a flex-cm bundle open the following command will use it: pull will save downloaded configurations in the bundle (use with 'open --source <source>'), add/update will merge from this bundle to the target environment (use with 'open --target <target>)

 

Important hints:

• You can use `help <command>` any time for more info.
• Auto-complete is supported, typing `<Tab><Tab>` will complete the command.
• Most of the configurations support specifying the following as parameters:
  • `--type`: to specify the object to use (e.g. `pull --type account` will pull only accounts).
  • `--uuid`: to define specific uuid object to use (e.g. `pull --type account --uuid <UUID>` will pull this specific object).
  • `--environment`: to define specific environment to use (e.g. `pull –environment <target>` will pull configurations from specified environment). As a reminder, you can list available environments with the following command: `showrepos`.
  • If none of these are defined, the command will attempt to do all and use source environment e.g.: `pull` will pull all configurations from source environment, `add` will try to add all new configurations from source to target environment.

Open and sessions 

open --source <name_of_source_env> --target <name_of_target_env>

This command creates a new change request. With this command, you can change which environment is your source and which is the target for a particular change session. Source and target environment are optional depending on the other commands you’d like to perform later.

This will create a changrequest session

open -–cr <change_request_name>

Allows to load change request session previously created. The change request name can be either taken when the previous open was performed or using session.

session --configure <key:value>

This command allows you to modify some of the modifier parameters. Notice that some of these are also available on the open command.

key (values)	Description
keep_visibility (true, false)	Defaults to true, on commit the visibility dependent will be mandatorily used (true) or skipped (false).
keep_visibility (true, false)	On commit the visibility dependent will be mandatorily used (true) or skipped (false). Defaults to `true`.
keep_organizational (user, account, all, none, all_with_fallback_to_none)	`user`: All user owners of the source object will be used mandatorily. If any of the referenced users do not exist, the commit will fail. In this case, account will behave as none above, it will be overwritten with flex-cm calling account. `account`: All account owners of the source object will be used mandatorily. If any of the referenced `all`: All user and account owners of the source object will be used mandatorily. If any of the referenced users or accounts do not exist, the commit will fail. `none`: All user and account owners of the source object will be ignored, and the user/account configured to commit configurations in flex-cm target will be used. `all_with_fallback_to_none`: All user and account owners of the source object will be attempted. If any of the referenced users or accounts do not exist, the commit will default to the user/account configured in flex-cm to operate with the target environment. `accounts`: Do not exist, the commit will fail. In this case, user behave as none above, it will be overwritten with flex-cm calling user.
keep_assignment_task (all, none)	`all`: TDB `none`: Will remove from committed target task configuration assigned objects. Defaults to `all`.
keep_organisational_metadata_def (all, none)	`all`: TDB `none`: Will remove from committed target metadata definition configuration user/account referenced in permissions.   Defaults to `all`.
keep_site_uuid (source, target)	`???`: Scratch source site UUID on target environment. Default to `source`.
skip_tag_metadata_def (true, false)	`true`: Will maintain from committed target metadata definition configuration referenced tags. `false`: Will remove from committed target metadata definition configuration referenced tags.   Defaults to `true`. Note: Used only on pulling.
skip_taxonomy_metadata_def (true, false)	`true`: Will maitain from committed target metadata definition configuration referenced taxonomies. `false`: Will remove from committed target metadata definition configuration referenced taxonomies. Defaults to `true`. Note: Used only on pulling.

Session output also shows if there is any mapper, or bundle, loaded (see below for more info on this topic).

HINT: Reminder to use auto-completion and help for more information from flex-cm tool itself.

Pulling configurations

pull

Pull objects from the source environment. If you execute the command by itself without specifying an object type, flex-cm will pull all the available object types by default.

pull -environment target

Pull from target environment only

pull --type action

Take all the actions from the source environment

pull --type action –uuid <uuid

Take specific action from the source environment

pull –scope <uuid> or pull –scope masteraccount

Pull uuid/masteraccount, only pull objects owned by this account. Notice that ‘masteraccount’ is magic word here. This can be combined with above.

pull –dependency downstream_reference

Pull dependency objects resolved from given object. Use downstream_reference to get children dependencies. Value must be 'upstream_reference | downstream_reference | both_reference|ownership|ownership_skip_users'

pull --type account --lastModifiedOffsetSecond 3600 --dependency ownership --uuid a0d2c905-6041-41d5-a672-308a53852f47

Pull all changes of given uuid in the last x sec

pull --type workflow_definition --scope b8605bb5-6a81-4e25-a99b-092867f8dbe8

Pull all workflow definition from account

pull --type tag_collections

tag collections should be pulled and separate json should be added to source for each tag collection pulled. This object doesn’t support uuid selection

dependencies  --uuid 029478e5-8f1b-44ed-8e1b-1f6897c65048 --summary

--------------------- DEPENDENCIES -------------------- 

UUID: 029478e5-8f1b-44ed-8e1b-1f6897c65048, Name: test ps, Id: 101957

Allow to find out dependencies for given object.  

--depth to define how deep the dependencies is explored in the graph

--summary for quick overview

--saveFile to save json result locallly

Additional examples

pull --type account

pull --type account_property pull --type role

pull --type user

pull --type group

pull --type workspace

pull --type resource

pull --type metadata_definition

Pull configuration params

pull --type workflow_definition

pull --type action

pull --type resource

pull --type event_handler

pull --type message_template

pull --type timed_action

pull --type user_defined_object_type

pull --type wizard

pull --type profile

pull --type player_definition

pull --type taxonomy

pull --type tag_collections

Preparing commits: changeRequest

add 

This will add from open session source environment to target environment those configurations that do not exist in the target environment folder.

Reminder that uuid, type, environment config param modifiers applies

add --dependency downstream_reference --uuid <uuid>

This will attempt to add only the given uuid with downstream_reference. Previously a pull with dependency should have been used to reference this now.

add --type tag_collections

all tagCollection should be added to target folder. This object doesn’t support uuid selection update

This will copy from open session source environment to target environment those configurations that have changed in the target environment folder. Comparison is done checking if source/target json files are different.

Reminder that uuid, type, environment config param modifiers applies

commit –reference_map prepare

This is required to pull all references from pulled configurations after all add/update/delete command have been performed. It is recommended in all cases.

This will go through all configurations in target environment copied and access the source environment to pull out the uuid used by dependent objects (e.g. a Metadata Definition referencing an object via id, with reference_map prepare, flex-cm will fetch from the source environment the uuid. This uuid will be used later in target environment to remap the object to the local id in the target environment).

Additional examples:

• Dependency works with add and commit

open --source <source_name> --target <target_name>
pull --type workflow_definition --dependency downstream_reference --uuid b8605bb5-6a81-4e25-a99b-092867f8dbe8
add --dependency downstream_reference --uuid b8605bb5-6a81-4e25-a99b-092867f8dbe8
commit --dependency downstream_reference --uuid b8605bb5-6a81-4e25-a99b092867f8dbe8

Committing configurations

commit

This will commit to the target environment all configuration prepared with add/update/delete.

Reminder that uuid, type, environment config param modifiers applies.

Commit will return a summary of all objects and the result in Flex Core classified by successful, warning and conflict messages.

Commit will attempt to report progressively intermediate messages coming from Flex Core while the transaction is happening in the target environment.

Users are required to analyze the result and check in Flex Core UI the result of the committed configurations.

Note: In case of tagCollection all tagCollection will be committed. tagCollection does not support uuid selection

commit –-reference_map use

This will commit to the target environment all configuration prepared with add/update/delete, in this case using the reference_map that should have been created with commit --reference_map prepared on the source environment. It is recommended in all cases.

Reminder that uuid, type, environment config param modifiers applies              

flex-cm additional features

Mappers

mapper –file <file-location>

The mapper command allows you to map a user, account, or visibility from one environment and apply it to an object located in another environment using UUIDs.

The mapper command does not map internal configuration references. For example, an action using a metadata definition in the configuration will not have the UUID mapped. Only access details are mapped: such as user, account, and visibility.

You need to specify the UUID of the object type you wish to map, and then the UUID of the object you want to map it to.

To use this command, you must first specify the object UUIDs in a JSON file. For example you could have the following:

 {
  "mapping": [
    {
      "sourceUuid": "4508649d-d697-4c75-8fa0-27ac4ca674c4",
      "targetUuid": "786a8a14-6533-41c9-ad22-8a54fe9bcbd9"
    }
  ]
}

Note: The location of the file should consider the docker image volume mount point, e.g.: /root/flexcm_repository/cmexamples/source/mapper.json

At this point of time flex-cm + Flex Core do not support mappers to create new objects in the same environment but 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 the same as the source environment.

flex-cm Bundles 

flex-cm bundles are configurations captured using flex-cm pull and prepared to be reused across multiple environments. This can involve any combination of object supported by flex-cm (e.g. workflow definition, action, resources, profiles...).

flex-cm bundles are stored in flex-cm file repository at the same level as flex-cm environment folder. They contain:

• A folder for each configuration object pulled from source environment, same as environment
• A bundle.json and mapped_reference files maintained automatically by flex-cm bundle command
• A README.md that should be filled in by user explaining what is inside

Creating a bundle and pulling configurations

Bundles can be created or loaded using the flex-cm bundle command. It requires a flex-cm session open. In this case, min requirement is to have the source only.

pull operations will pull configurations from the –source environment and save them in the bundle object folder. It will update the bundle.json and README.md with default values.

When all configurations are pulled you should use ‘bundle --operation reference_map’ to prepare the reference_map (see above reference_map) for this bundle.

open --source <source_environment_name>
bundle --name test-01 --operation create 
pull --type workflow_definition –uuid <uuid> --dependency downstream_reference bundle --operation reference_map 

Using a bundle

Applying a bundle requires opening a session with a minimum target environment. Then load the bundle and add and/or update configuration to the changerequest session. This will copy configurations from the bundle into the target environment folder. It will also copy the reference_map to the current changerquest (CR folder)

Finally, commit using reference_map:

open --target <target>
bundle --name test-01 --operation load add update 
commit --reference_map use 

flex-cm scripts

flex-cm scripts are a sequence of flex-cm commands executed in order, e.g. save this in a .cm configuration

open --source <source_environment_name> --target <target_environment_name>
pull --type action --uuid 37339915-c8bd-40b9-9068-bc54413a7bd0
pull --type action --uuid 5488c981-36da-43b3-be8d-25e29cd7480b
pull --type action --uuid 379874ba-0782-4c03-bef9-a3ba45b80b93
pull --type workflow_definition --uuid b8605bb5-6a81-4e25-a99b-092867f8dbe8 add
commit

Then execute flex-cm script (see below flex-cm setup).      

flex-cm setup

Note: see Introduction – Quick Walkthrough for more info

Configure flex-cm local repository and flex-cm environments

Create a directory where the flex-cm file configuration repositories will reside, e.g.: if storing in flexcm_repository

~/flexcm_repository/demo

Configure base setup: create a file in user home (Linux) ~/miocm-config.yml with the following info 

defaultRepository: demo
defaultPath: /root/flexcm_repository 

Notice: defaultPath is usually fixed as it refers to the docker volume location

Get flex-cm and execute it, replace <your-user> below and try starting flex-cm. 

Pull the docker image using

docker pull registry.services.ooflex.net/flex/flex-cm

Run the docker image using

docker run --rm  -v /home/<your-user>/miocmconfig.yml:/root/miocm-config.yml -v /home/<youruser>/flexcm_repository:/root/flexcm_repository -it registry.services.ooflex.net/flex/flex-cm  

Configure the source environment you are going to try first, e.g.: if you have not configured any environment replace your data below and run:

environment --envname <source_environment_name> –endpoint https://<youraccount.domain>/api --username <username> --password <password> 

Quick verification, flex-cm commands:

showrepos
session
open --source <source_environment_name>
list --type actions

Running flex-cm options

Note: Below $(pwd) assumes you are using Linux

Running docker interactively

docker pull registry.services.ooflex.net/flex/flex-cm 
docker run --rm  -v "$(pwd)"/miocm-config.yml:/root/miocm-config.yml -v 
"$(pwd)"/flexcm_repository:/root/flexcm_repository -it registry.services.ooflex.net/flex/flex-cm 

Running docker to execute a cm script that you have previously prepared

docker run -it --rm -e HEAP_SIZE=512 -v 
$(pwd)/flexcm_repository:/root/flexcm_repository -v $(pwd)/miocmconfig.yml:/root/miocm-config.yml registry.services.ooflex.net/flex/flex-cm -execute='script --file /opt/flex-repo/flex-cm/miocm-docker-poc.miocm' 

Customized defaultPath

docker run --rm -e HEAP_SIZE=512 -v $(pwd)/flexcm_repository:/root/flexcm_repository registry.services.ooflex.net/flex/flex-cm --defaultPath="/root/flexcm_repository" -execute='script --file /opt/flex-repo/scripts/cron-source-to-target.miocm' 

 Running docker periodically, you might want to control if CM should run or skip (this is used in Multisite for CM replication)

docker run --rm -e HEAP_SIZE=512 -v $(pwd)/flexcm_repository:/root/flexcm_repository registry.services.ooflex.net/flex/flex-cm --defaultPath="/root/flexcm_repository" -execute='script --file /opt/flex-repo/scripts/cron-source-to-target.miocm' --cmmultisite=true 

flex-cm random tips and troubleshooting

git repositories

As flex-cm uses filesystem repository to manage configuration, by setting up a git repository pointing to this folder, users should be able to use git to track configurations pulled/added/update/committed by flex-cm.

Resource Tags

Reference resource by tags from Actions. This will give you the abstraction to move configuration across environment without Action-Resource rigidity.

Account Properties

Use expression and account properties in configuration parameters when you can if they need to be different across environment. Then you can define custom configuration properties per environment.

Workflows and Script aware of running environment

Workflows and script can be designed/implemented to have different logic depending on the environment where they are running. One possible option is to use from script the Flex environment site uuid to make dynamic decisions. e.g:

def execute() {
  def flexSiteUuid = context.asset.flexSiteUuid as String
  if(flexSiteUuid.equals("14652f56-e449-11e4-8a00-1681e6b88ec1")) {
    return true
  } else if (flexSiteUuid.equals("44652f56-e449-11e4-8a00-1681e6b88ec1")) {
    return false
  }
}

Committing a new User

Dalet 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:

1. 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.
2. 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).
3. The third change request: is to create and progress new users from your source environment to your target environment.

TagCollection does not support Metadata Definition re-mapping

TagCollection does not have uuid at this point of time. tagCollection can be pulled altogether from source to target but Metadata Definition will not relink the tagCollection. If Metadata Definition are using tagCollection they should be committed with skip tag collection option (see flex-cm session) and then relink them manually on target environment.

User Passwords

If you transfer a new user from your source environment to the target environment, the new user might not be able to login via the UI, until the super user has reset that particular user’s password.

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.

Accounts

If you want to create a new account in an environment via flex-cm, 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.

Workflow Definitions / Events

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.

Creating a new account using a variant with a metadata definition of the same account 

Creating a new account using a variant with a metadata definition of the same account might fail if created in the same change request

Workaround for this problem:

1. First create a change request to deploy the account. A warning will be shown, that informs you the metadata definition cannot be referenced to create the variant.
2. Open a new Change Request to deploy the metadata definition only.
3. 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.