Using Dynamic Values from Variables in Workplace Service Delivery Task Templates

[Daniel Borkowi1]

Intro

When I recently needed to populate a Workplace Service Delivery task with dynamic values from Workplace Case variables, I was surprised that this pattern was not widely known. The assumption was that a more complex workflow would be required.

In reality, the solution is quite simple.

With a standard sys_template, a small global Script Include, and the required cross-scope privilege, you can dynamically render values from variables directly into a Workplace task created by a Workplace Service Delivery activity.

This article shows the approach I used in a small proof of concept.

The use case

I wanted to create a Workplace Service Delivery task where the task content is filled dynamically based on variables from the originating record.

For the PoC, I used the out-of-the-box Equipment service from the Workplace Service Delivery demo data and created a new service activity:

• Service Activity: DBOR Test Activity
• Activity type: Task
• Task table: Workplace Task [sn_wsd_core_workplace_task]
• Default template: DBOR Equipment Task Template v6

Screenshot 1 – Workplace Service Activity configuration

Why this is interesting

Workplace Service Delivery task templates are based on sys_template records. That means you can use the same familiar template capabilities, including javascript: expressions.

In a simple/global scenario, you might expect something like this to work:

short_description=javascript:"Test task for " + current.variables.requested_for^state=10^EQ

However, in the Workplace Service Delivery / Workplace Case Management scoped context, accessing variables in this way is not always straightforward.

The clean workaround is:

1. Pass the current record into a global Script Include
2. Read the variables there
3. Return the value you want to render into the template

This keeps the solution lightweight and avoids building unnecessary workflow complexity.

Step 1 – Create the task template

I created a template called:

• Template name: DBOR Equipment Task Template v6
• Table: sn_wsd_core_workplace_task

The important part is the Template field:

short_description=javascript:new global.DBOR_Variable_Query().getRequestedFor(current)^state=10^EQ

What this does:

• Calls a global Script Include named DBOR_Variable_Query
• Passes the current record into the function getRequestedFor(current)
• Uses the returned value as the short_description

Screenshot 2 – Task Template with dynamic JavaScript

Step 2 – Create a global Script Include

Next, I created a Script Include:

• Name: DBOR_Variable_Query
• API name: global.DBOR_Variable_Query
• Application: Global

Most importantly:

• Accessible from: All application scopes
• Active: true

Example code from the PoC:

var DBOR_Variable_Query = Class.create();
DBOR_Variable_Query.prototype = {

    initialize: function() {
    },

    getRequestedFor: function(gr) {
        return "Test: " + gr.variables.requested_for;
    },

    type: 'DBOR_Variable_Query'
};

In this proof of concept, the function simply returns the value of the requested_for variable.

Of course, this is where you can implement more advanced logic, for example:

• formatting values
• resolving references
• building composite strings
• performing lookups
• applying conditional logic

Screenshot 3 – Global Script Include

Step 3 – Allow cross-scope access

Because the template is executed from the Workplace Case Management context, the scoped application must be allowed to call the global Script Include.

For that, I created a Cross-Scope Privilege with these settings:

• Source Scope: Workplace Case Management
• Target Scope: Global
• Target Name: global.DBOR_Variable_Query
• Target Type: Script Include
• Operation: Execute API
• Status: Allowed

Without this step, the scoped application will not be able to execute the Script Include.

Screenshot 4 – Cross-scope privilege

How it works

At runtime, the template evaluates this expression:

javascript:new global.DBOR_Variable_Query().getRequestedFor(current)

The current record is passed into the Script Include, and inside the Script Include you can access:

gr.variables.requested_for

The returned string is then written into the target field defined in the template, in this case - Short Description.

Why this approach is useful

This pattern is useful because it avoids overengineering.

Instead of building a complex workflow only to move variable values into a task, you can keep the solution very small:

• one standard sys_template
• one small global Script Include
• one cross-scope privilege

For me, this is much closer to tailoring than to heavy customization.

It also gives you a reusable place to add more logic later, without redesigning the overall process.

Conclusion

If you need dynamic values from variables in a Workplace Service Delivery task, you do not necessarily need a complex flow.

A much simpler pattern is:

1. Use a standard sys_template
2. Call a global Script Include from the template via javascript:
3. Pass in current
4. Read the variables in the Script Include
5. Allow the call with a cross-scope privilege

That is enough to dynamically render variable-based content into Workplace tasks with minimal effort.