Re: UI Action - 'Condition' not applying on Worksp...

Andrew McNeill · ‎07-25-2023

@Dharaneetharan @Manmohan K yes I have found the solution

The solution is, the condition for workspace UI actions isn't toggled from the UI Action record

Instead, it is toggled from a record on the Action Assignment [sys_declarative_action_assignment] table

Within the record, you must click Advanced view in the related links, and you may have to configure the layout to show the 'Script Condition' field under the Conditions tab

Only here could I control visibility of UI actions in Workspace

View solution in original post

Eswari K · ‎04-26-2024

Hi @Andrew McNeill, I've created a UI action for workspace. But i can't able to create action assignment.

mattmm · ‎08-19-2024

Hi @Andrew McNeill , when you say "Advanced View in the related links" do you mean on the UI action or somewhere else? Related links in my UI action only shows Default View?

abirakundu23 · ‎06-25-2024

Hi @Andrew McNeill ,

I have tried approach that you have shared in here. We have tried to Call our script include from Script condition for visibility. But entire script include is running properly but button still visible for that.

// new hr_CaseTransferAjax_copy1().validation(); (for condition added script include)
script condition: current.active && gs.hasRole('sn_hr_core.case_writer') && (current.hr_service.value != sn_hr_core.hr.BULK_PARENT_CASE_SERVICE) && new sn_hr_core.hr_Utils().canRenderUIAction(current,'transfer_case') && new hr_CaseTransferAjax_copy1().validation();

Script include: (Which is not client callable)

var hr_CaseTransferAjax_copy1 = Class.create();

hr_CaseTransferAjax_copy1.prototype = {

validation: function() {

var checks = false;

//var casesysid = this.getParameter('sysparm_sys_id');

var caserecord = new GlideRecord('sn_hr_core_case');

caserecord.addEncodedQuery('u_validation_required=Yes^active=true');

caserecord.addQuery('sys_id', current.getValue('sys_id'));

caserecord.query();

// if (caserecord.u_validation_required == "Yes") {

var count = 0;

//var case_record = caserecord.sys_id;

var case_record =current.getValue('sys_id');

gs.info('case record:' + case_record);

var task_table = new GlideAggregate('sn_hr_core_task');

var temp = gs.getProperty('sn_hr_core.ValidationTask');

task_table.addEncodedQuery('active=false^template=' + temp + '^parent=' + case_record);

task_table.addAggregate('COUNT');

task_table.query();

while (task_table.next()) {

count = task_table.getAggregate('COUNT');

gs.info('Count is' + count);

//while (task_table.next()) {

if (count == 0) {

gs.info("if Count is " + count);

//checks = false;

gs.info("if Count is 12 " + count);

return false;

} else {

//checks = true;

gs.info("else Count is " + count);

return true;

}

//}

//return checks;

},

type: 'hr_CaseTransferAjax_copy1'

};

Henalu · ‎03-23-2026

The condition field on the UI Action record is evaluated in classic UI, but in Workspace the platform ignores it and defers to sys_declarative_action_assignment instead — which follows different rules entirely.

This is especially tricky with Experience Restricted: enabling it changes the scoping behavior and can cause the action to not appear at all in custom workspaces. The most reliable fix is to put your condition logic inside the Server Script and let it control visibility from there.

I documented the full behavior and the workaround here (in Spanish, Google Translate handles it well): https://breaking-trail.vercel.app/articulos/workspaces/declarative-actions-experience-restricted-dyn...