Help needed to modify Normal Change Model

gjz
Mega Sage

2 hours ago

We are trying to use the new Change Models, but I'm having trouble getting it to work.  We implemented Change Management in 2018, I have run the migration process to use the models.

 

Because we are a small company, 90+% of our normal changes do not need to stop at the Assess state.  With legacy change, we fixed this by adding a Peer Review flag and if it was checked, the Change Request went from New > Assess, otherwise, if it's not checked, move from New > Authorize.  I need the same functionality with Change Models, but I'm not getting the expected result. 

 

On the Change Request form, I'm getting two "Request Approval" buttons instead of one.  One button will move to the Assess state, the other moves to Authorized.  I only want one button and move to the appropriate state based on whether or not the Peer Review flag is checked.

gjz_1-1769642004615.png

 

Here is what I've done:

1. Create a new Approval Definition called "Peer Review Approval" for the appropriate approval group.

2. Changed the Change Approval Policy "Normal Change Policy"

a. Added a Decision for Peer Review Approval

gjz_2-1769642303356.png

 

3. Modified the Change Model "Normal"

In the "New" state:

a. Added a state transition "New to Authorize"

gjz_4-1769642505553.png

with the Model State Transition Condition:

gjz_5-1769642574897.png

b.  Modified the OOTB state transition "New to Assess" to include a Peer Review state transition condition.

gjz_6-1769642744757.png

 

Added a condition to the Workflows to include "Model is empty" to make sure the workflows don't run and Flows (Flow Designer) are used instead.

 

What am I missing?

 

Thanks!

0 Helpfuls
  • 108 Views
1 REPLY 1

Itallo Brandão
Tera Guru

53m ago

Hi @gjz ,

Based on your description and screenshots, your Change Model backend configuration is actually correct! You have correctly set up the transitions based on the Peer Review flag.

The issue is not with the Model logic, but with the UI Actions (the buttons themselves).

In the "Change Models" paradigm, standard buttons often check canMoveTo('state_name'). Since your model technically allows paths to both Assess and Authorize (depending on conditions), the system might be trying to render the specific buttons for those transitions, or you are seeing a conflict between a Legacy Workflow button and a Model button.

To get the single "Smart Button" behavior you want, the best practice is to create a custom UI Action that handles the logic and hide the OOB ones.

Here is how to solve it:

Step 1: Hide the Duplicate/OOB Buttons

  1. Right-click the form header > Configure > UI Actions.

  2. Search for Name contains "Request Approval".

  3. You will likely find state_model_request_assess_approval or generic request_approval buttons.

  4. For the buttons you want to hide on Normal changes, modify the Condition to exclude your type:

    • Change: ... && current.type != 'normal'

    • (Alternatively, uncheck "Active" if you don't use them for other types).

Step 2: Create the "Smart" UI Action

Create one button that checks your checkbox and directs the ticket to the correct path.

  1. Name: Request Approval

  2. Table: Change Request [change_request]

  3. Action name: request_approval_normal_smart

  4. Form button: Checked

  5. Condition:

    current.type == 'normal' && current.state == -5 && new sn_change_model.ChangeRequestStateHandler(current).isNextStateAvailable()

    (Note: State -5 is 'New'. Adjust if necessary).

  6. Script:

// Ensure record is saved so the checkbox value is current
if (current.isNewRecord()) {
    current.update();
}

// Initialize the Model Handler
var stateHandler = new sn_change_model.ChangeRequestStateHandler(current);

// REPLACE 'u_peer_review' with the actual column name of your flag
if (current.u_peer_review == true) {
    // Path A: Peer Review is needed -> Go to Assess
    if (stateHandler.canMoveTo("assess")) {
        stateHandler.moveTo("assess");
    } else {
        gs.addErrorMessage("Cannot move to Assess. Check Model transitions.");
    }
} else {
    // Path B: No Peer Review -> Skip to Authorize
    if (stateHandler.canMoveTo("authorize")) {
        stateHandler.moveTo("authorize");
    } else {
        gs.addErrorMessage("Cannot move to Authorize. Check Model transitions.");
    }
}


Why this works: Instead of relying on the button visibility to guess where the ticket should go, this script forces the logic at the moment of the click. It acts as a traffic controller, sending the ticket down the correct "pipe" defined in your Change Model.

If this solution fixes your button behavior, please mark it as Accepted Solution.

Best regards,
Brandão.

0 Helpfuls