Custom Edit Button under change request in SOW is not clickable

[surajbiswal]

I have created a Edit action button in RITM --> related list--> change request on SOW view

But the button is not clickable User can't edit and add the existing CR in ritm and also can't remove the CR.

[Rohit Ladda]

You mean to say once you Click on EDIT button unable to See any change requests? Does the user has EDIT access on CR table? How is your RITM and CR table linked?

[surajbiswal]

Yes if i click on the edit button then it should allow me to select change request and i have admin access.

sys_m2m_template. Also there is an edit button for Native UI which is working perfectly.

[Rohit Ladda]

Need more details like how table are linked, screenshot of EDIT button when impersonating end user, etc.

[Terry_Yeti]

I ran your custom Edit button not being clickable in Service Operations Workspace (SOW) for Change Requests through snowcoder ai. This is a known pattern with workspace UI actions and declarative actions in SOW.

Here are the most common causes and how to fix them:

## 1. Declarative Action Configuration

In SOW, traditional UI Actions don't always render the same way as in the classic UI. If you created a custom button as a **UI Action**, you likely need to create it as a **Declarative Action** instead (or in addition to) for it to work in workspace views.

- Navigate to **sys_declarative_action_assignment** and verify your action is properly assigned to the `change_request` table.
- Make sure the **Specify Workspace** field includes your SOW workspace (e.g., `sn_change_cab` or `sn_service_operations`).
- Ensure the action's **Form factor** is set to include **Workspace/Configurable**.

## 2. Check Action Conditions and ACLs

If the button renders but isn't clickable (appears greyed out or unresponsive), it's likely a condition or security issue:

- Verify the **Condition** field on your declarative action isn't evaluating to false for the current record state.
- Check that the logged-in user's role satisfies any ACL or role requirements on the action.
- If you have a **Client Action** script tied to it, open the browser console (F12) and look for JavaScript errors when clicking. A script error will silently prevent execution.

## 3. Verify the Action Model and Implemented As

When configuring the declarative action:

- **Action model**: Should be `Form Action` if you want it on the form header.
- **Implemented as**: If using a UX Client Script, make sure the script is valid and the **API Name** matches exactly.

Example of a simple declarative action client script:

```javascript
(function(actionPayload) {
var gForm = actionPayload.gForm;
// Example: set a field and save
gForm.setValue('state', '2');
gForm.save();
})(actionPayload);
```

## 4. Known SOW Issues with Buttons

Based on the Zurich release notes, there are several known issues with buttons in SOW for Change Management. For example, PRB1900447 documents a scenario where buttons fail to execute when mandatory fields aren't filled, displaying an error like "The following mandatory fields are not filled in..." - even when the action shouldn't require those fields. Check if your form has empty mandatory fields that might be blocking the action silently.

## Quick Debugging Steps

1. Open browser DevTools (F12) and go to the **Console** tab.
2. Click the button and check for any errors.
3. Go to the **Network** tab, click the button, and see if any API call is being made (or failing).
4. Temporarily remove any conditions on the declarative action to rule out condition logic.

If you share the specific configuration of your custom button (UI Action vs. Declarative Action, any conditions, and the script), I can help pinpoint the exact issue. But the most common fix is migrating from a classic UI Action to a properly configured Declarative Action with the correct workspace assignment.

_______________________________________
I used snowcoder ai to generate this. If you need to tweak the requirements, you can run it through their Yeti AI for free.