Procedure for Adding a State to a Policy

You can add states to an existing policy to further configure your application. For example, you for a policy that has Inactive and Active states, you might want to add an Approval state between.


Before you begin:
  1. Define and program any triggers that should be executed when the object governed by the policy is promoted from this state to the next state. See Designing Triggers for details.

  2. In Business Modeler, locate the policy and open it for editing.

  3. Insert the new state:

    1. Click the States tab.
    2. Highlight the state that you want to be immediately after the state you are creating.
    3. Click Insert.

      An Untitled state is added to the list of states.

    4. Select the untitled state and click Edit.

  4. Define the basic information for the new state:


    • Name. Enter a name. You also need to define a string resource so that the name can be internationalized, using this syntax:
      emxFramework.State.<Policy Name>.<State Name>=<State Name Translated>

      where:

      • emxFramework.State is the key that groups all the state names with in the FrameworkStringResource file.
      • <Policy Name> is the actual name of the policy to which the state is associated. The blank spaces are replaced with "_".
      • <State Name> is the actual name of the state for which translation is required. The blank spaces are replaced with "_".
      • <State Name Translated> is the translated value for the specified state name.

      As an example, to name the Approval state in the Master Document policy, the string resource would be:

      emxFramework.State.Master_Document.Approval=Approval

      Also add this line to the FrameworkStringResource file (where the other states in this policy are defined), and for each specific language string resource file.

    • Versionable. Check this box if you want to allow a file to be checked into the object when it is in this state (if the object allows for check-ins).
    • Revisionable. Check this box if you want to allow users to make revisions of the object when the policy is in this state.
    • Promote. When checked and a signature (approved or ignored) is applied, ENOVIA Live Collaboration tries to promote the governed object. If all signature and check requirements are satisfied, ENOVIA Live Collaboration automatically promotes the business object. If the state does not have any signatures or check requirements, this setting has no meaning.
    • Checkout history. Check this box if you want a history event to be recorded whenever a user checks out a file from this object when it is in this state.

  5. Click the Access tab.

  6. For each role or group that needs access to the object governed by this policy, follow these steps:

    1. Click Add.

      Business Modeler adds an Access icon for User to the list.

    2. Select the newly-added access item and click Edit.
    3. Click the ellipsis button to the right of the For text box.
    4. Search for and select the role or group.
    5. Check the accesses you want to assign to the selected role or group.
    6. Optionally, add a filter in the Filter text box. (See "Using a Filter Expression" in the Business Modeler Guide for details.) When the expression evaluates to “true,” the specified access is granted.
    7. Click OK to save the access definition for this role or group.

  7. If you defined triggers, follow these steps for each trigger:

    1. Click the Triggers tab.
    2. Click Add. The Trigger chooser opens, including an icon for each legal event for states.
    3. Select the Trigger state (such as Promote) and click OK. The Trigger state shows in the Triggers tab.
    4. Double-click the newly-added trigger icon.

      The Edit Trigger dialog opens.

    5. Click for the type of trigger you are adding (Check, Override, or Action). The Program Chooser opens.
    6. Select the needed program.
    7. In the Input field to the right of the Check, Override, or Action field, define arguments to be passed into the program. The arguments are referenced by variables within the program. Variables 0, 1, 2, and so on are reserved by the system for passing in arguments.

      Environment variable “0” always holds the program name and is set automatically by the system.

      Arguments from the Input field are set in environment variables "1", "2", and so on.

      See "Using the Runtime Program Environment" in the ENOVIA Studio Modeling Platform Programming Guide for additional information on program environment variables.

    8. Click OK to save the trigger definition.

  8. If you want notifications to be sent to users, follow these steps:

    1. Click the Events tab.
    2. If you want users to be notified when the object reaches this state, click in the Notify Message box and type the message you want emailed to users.
    3. In the Notify Users box, click the ellipsis button to select roles and groups for receipt of the message.
    4. If you want a message sent to someone when the object is reassigned to them, click in the Route Message box and, type the message you want emailed to that user.
    5. In the Route User box, click the ellipsis button to select the select the role or group who should receive ownership and be notified.

      Note: Instead of using Check and Action programs, ENOVIA recommends that you use triggers to perform verifications when an object is promoted from one state to the next.

  9. Click OK to save the state definition.

  10. Click Edit to save the changes to the policy.