Deployment of the modified configuration entity

After someone approves the modified entity, you or anyone with the appropriate access rights must deploy the entity. Figure 1 shows the record changes that occur when someone deploys the configuration entity.

Figure 1. The record changes for the deployment of the modified configuration entity
Figure showing the record changes for the deployment of the modified configuration entity

After you or another user deploys the approved changes in level 2, FTM SWIFT creates a new record. This record has the same level as the approved record but with the life-cycle state Deployed.

Security entities are moved to the Active state when you approve them. They do not go through the Deployed state.

Only one occurrence of an entity can be active at a time. When you put the modified entity into production, this entity changes from the In process state to the Active state. At the same time, the previously deployed version of the entity changes from the Active state to the History state. The level state Active was moved from level 1 to level 2. All records before the currently deployed record always have the level state History.

Notes:
  1. When you use the list command to view FTM SWIFT entities, you see only the information with the Active or In process level state, depending on your query options.
  2. If you have a security entity with the life-cycle state Approved (AP) and you delete it (its entity state is D), it will not be listed among the active entities. Similarly, if you have a configuration entity with the life-cycle state Deployed (DP) and you delete it (its entity state is D), it will also not be listed among the active entities.
  3. If you use the cre (create) and del (delete) commands in the same level of an entity, you have no record of the created entity in the database. Therefore, you cannot see this change when you use the list command. You receive similar results when you issue the add and remove commands in the same level of the entity.
  4. You can use filters to obtain specific information. For example, you can list only roles that were approved by JSMITH. This produces a list of active roles that JSMITH approved.
  5. Some combinations of filter criteria result in nothing being listed because of conflicting values. For example, you can request to list all the approved CTs that were rejected by JSMITH. Since FTM SWIFT keeps the reject information only temporarily, it no longer exists if the same entity is now in the Approved state.
    More information is available in the following sections:
    • For a list of valid list command filter combinations, see List command filter criteria.
    • For a summary of results of the list command for parameters that specify user IDs and their actions in the configuration process, see List command results.
    • For a description of the syntax and parameters of the list command, see list (list command).
  6. To obtain information about the history of previous inactive configuration data, search the audit views. Database audit views describes how to retrieve the history on inactive configuration data.