Question to Codebeamer Development - WorkflowAction - execute field updates with different user context

Forum|Forum|20 days ago
June 30, 2026
2 replies
81 views

Hello all,

I've been tasked with creating some WorkflowActions that shall obtain data, process it and write the result to an item field (text, choice, table - differs per WA), where the triggering Member lacks write access to the field.

A use case is (e.g.) writing "administrative data" to item fields that are not visible to members with certain roles (e.g. "Externals" or "Non privileged" regular users). Since a WorkflowAction is, by design, always executed in the context of the triggering user, this cannot be achieved by default.

Is there a way to execute these field updates under a different user context (e.g. "system user") from within the WorkflowAction, or to run the WorkflowAction itself under a different context?

Another approach could be utilising the "Execute as" mechanism available for some "predefined" WorkflowAction (disabled by default) - is there a way to use this from a custom WorkflowAction (possibly with a "hard wired" user, defined in the WA)?

Any ideas or suggestions are welcome.

Last but not least, if this is the wrong place for this type of question I'm open for recommendations.

Thank you and regards

Best answer by BKampling_SAI

@snowy_21 While you don’t want additional states, that may be the best option here. If you have a state where these actions take place, you can configure access to the table and fields needed for the use only while in that state. You can then chain on another WA that would trigger a state transition out of that state and back to what the user would normally see. You should be able to have this so that state is only reachable from the WA and not reachable manually by the user. So in short, add bookends onto your WA chain for entering into a state allowing for field edits and then exiting that state at the end of the chain.

BKampling_SAI

14-Alexandrite

Hi @snowy_21 could you provide specific details as to the use case. I believe there is a way to do this, but I need more details, such as, does the triggering user need to see the field, will this occur in a specific status or all statuses, etc.

Thanks,

Brian

S

snowy_21

Author

8-Gravel

Hi @BKampling_SAI, thanks for your reply; actually we have use cases for all the scenarios you mentioned.

The primary one is obtaining data through a computation to build (i.e. populate) a table. This table is visible to non-external members/roles in all states but shall not be editable by any member/role (read only).
It summarises project status data and consists of a fairly large number of columns (>10) and rows (>70). Populating it via column-wise computations has proven impractical (workload, time). Populating the table through a WorkflowAction (Change Handler w/ condition) is significantly more efficient, but requires write access to the table.

Another use case involves computing a list of (item) ID Nos. and writing it to a dedicated field of a target item. This also requires write access to the field for the member/role executing the WA.
The sole purpose of this field is to provide data for Word exports (the target item serves as configuration item), it has no "active role" in any of our workflows, so we would prefer to generally disable read access to it.

Note: not sure if this is important, but all WorkflowActions are supposed to be executed with "WorkflowPhase.Before".

Regards
Stefan

BKampling_SAI

14-Alexandrite

Hi @snowy_21 there are a couple of potential approaches here. You can have a field be hidden conditionally, so you could have a change handler modifying the field without exposing the field on the UI, making it so the user, while they have edit access, can’t actually edit it because they can see it. If they also need to be able to see it, you can create a secondary field that leverages computed fields, making it read only, that would then display the data.

Let me know if this helps or if you want me to extrapolate on something.

BKampling_SAI

Answer

14-Alexandrite

@snowy_21 While you don’t want additional states, that may be the best option here. If you have a state where these actions take place, you can configure access to the table and fields needed for the use only while in that state. You can then chain on another WA that would trigger a state transition out of that state and back to what the user would normally see. You should be able to have this so that state is only reachable from the WA and not reachable manually by the user. So in short, add bookends onto your WA chain for entering into a state allowing for field edits and then exiting that state at the end of the chain.