Skip to main content
Declined

Influence "call-to-action" (primary action) task status via context procedure

Related products:Software FactoryUniversal GUIUI/UX
  • October 15, 2025
  • 5 replies
  • 73 views

Goal:
I would like to be able to change the primary action status of tasks via the context procedure.

Use case:
An ordering process with 3 statuses: new, ready to send, and sent.
I want to apply the call-to-action color to the task that triggers the correct next status in the process.

By default, I've configured the “new order” task as call-to-action.
However, when there is an order that is ready to be sent, I'd like to make the “send” task the call-to-action instead. Meanwhile, the “new order” task should still remain available to users as a regular task.

Workaround:
Currently, we can only achieve this by making duplicates of the tasks (1 regular and 1 call-to-action per status) and by using the context procedure to hide all the ones we don’t need per status. For 2-3 statuses this is okay, but for a process with a lot of statuses this quickly becomes very cluttered, both in the tasks and the context procedure. 

Solution:
In the context procedure, add a new type for tasks.
E.g.: @[task_name]_type -- tasks. 0 = enabled, 1 = disabled, 2 = hidden, 3 = primary action. (or use nr. 1 to follow the logical order, in that case also make an enrichment to change all existing context procedures)

5 replies

Bart Metselaar
Moderator
Forum|alt.badge.img+3
  • UI/UX Designer
  • 127 replies
  • October 15, 2025

Hi Ken!

It is ill advised to have your primary actions changing to a different button based on the context of the subject.
Shifting the Primary function across multiple buttons makes the concept not a primary button anymore. 
Compare it to our email tools.

The primary button should be a solid, single point of contact, drawing the attention of the user to a specific point. This keeps it recognizable and you can use this focus point to draw the attention to additional buttons in the vicinity of said Primary button.

When that visual point shifts based on a context (which the user should not be bothered with in my opinion), your surpassing that goal of the primary button. 

Important! There is a difference in shifting the primary button, and hiding the primary button and showing that button at a specific point (like we do with the ‘Save’ button in forms).

 

 
 


Bart Metselaar
Moderator
Forum|alt.badge.img+3
  • UI/UX Designer
  • 127 replies
  • October 27, 2025
NewDeclined

Freddy
Forum|alt.badge.img+16
  • Thinkwise Local Partner Brasil
  • 554 replies
  • October 27, 2025

Hi Ken!

It is ill advised to have your primary actions changing to a different button based on the context of the subject.
Shifting the Primary function across multiple buttons makes the concept not a primary button anymore. 
Compare it to our email tools.

The primary button should be a solid, single point of contact, drawing the attention of the user to a specific point. This keeps it recognizable and you can use this focus point to draw the attention to additional buttons in the vicinity of said Primary button.

When that visual point shifts based on a context (which the user should not be bothered with in my opinion), your surpassing that goal of the primary button. 

Important! There is a difference in shifting the primary button, and hiding the primary button and showing that button at a specific point (like we do with the ‘Save’ button in forms).

 

 
 

Hi ​@Bart Metselaar , 

I understand you point, but also the request. The point is that we also see more requests for guidance in bigger systems, e.g. knowing what to do. And this is difficult in Thinkwise applications if you ask me. There are little options to guide a user, see also the various topics on task/modal sequencing. 

I do see added value of steering the attention color of tasks based on a status of a subject.  So for example we have a new financial document upload. First task is to OCR the document..  then validate, then process, etc..   there are like 5 to 6 tasks and per 'state' there is a primary button. 

How do you look at these scenario's? 


Bart Metselaar
Moderator
Forum|alt.badge.img+3
  • UI/UX Designer
  • 127 replies
  • October 27, 2025

Hi ​@Freddy! I also understand the request, in which we are talking about guidance in a process. 
If we'd (mis)use primary actions as a means for guidance in a process, we are still not introducing support which we are clearly looking for: dedicated guidance.

A component like the stepper component would be a way better tool for those means, in which you as a developer would have a dedicated tool at your disposal to guide your users through steps of a process. In which we can offer the user a recognizable insight in elements like how many steps there are in a process, navigating backwords, whether process steps are completed or not, etc. 

 

 


Freddy
Forum|alt.badge.img+16
  • Thinkwise Local Partner Brasil
  • 554 replies
  • October 28, 2025

Hi ​@Freddy! I also understand the request, in which we are talking about guidance in a process. 
If we'd (mis)use primary actions as a means for guidance in a process, we are still not introducing support which we are clearly looking for: dedicated guidance.

A component like the stepper component would be a way better tool for those means, in which you as a developer would have a dedicated tool at your disposal to guide your users through steps of a process. In which we can offer the user a recognizable insight in elements like how many steps there are in a process, navigating backwords, whether process steps are completed or not, etc. 

 

 

Looking forward to an implementation of the stepper component :)