Writing Post-Functions (Actions)

Post-functions are the workflow actions on the workflow and are executed in the final stage of the a transition. They have no special return requirements on returns, and always consistently execute in the context of the transitioned issue.

A post-function may be as simple as:

assignee = currentUser();

Or , you can add complexity to meet a specific requirement.

Unlike validators and conditions, the post-function is the only place in the workflow where you can modify the issue.

Parameters

On the Cloud, the only derived parameter is the post-function ID. It is passed as the only parameter in the script execution of the script, allowing you to create decisions.

An example is below:

And the corresponding script:

logPrint("ERROR", "Postfunction execution - Current user is :" + currentUser() + " postfunction id:" + argv[0]);

switch(argv[0]) {
    case "e6132922-74c4-4315-84f0-32bcb70cddf4": //this is the first postfunction
        logPrint("ERROR", "This is the end, my only friend " + currentUser());
        break;
    case "9c5bbeda-f20c-44ae-bda4-272203e3b412": //this is the second postfunction
        logPrint("ERROR", "The end of our elaborate plans, the end of everything that stands");
        break;
}

The output is (on the ERROR level, where the message was pushed):

Postfunction execution - Current user is :6093b81a539c14006ad3c137 postfunction id:e6132922-74c4-4315-84f0-32bcb70cddf4
This is the end, my only friend 6093b81a539c14006ad3c137
Postfunction execution - Current user is :6093b81a539c14006ad3c137 postfunction id:9c5bbeda-f20c-44ae-bda4-272203e3b412
The end of our elaborate plans, the end of everything that stands

Even if the script is the same, the different integration points generate unique IDs (on different transitions and workflows). Therefore, you may use this strategy to apply small changes to the logic depending on your location. However, these IDs are not portable from install to install.

The goal is for this information to assist you in script reusability.

Runtime User & Issue

Post-functions execute with the user activating the transition, no matter if it’s declared as asynchronous or synchronous. If the transition is triggered by another automation or addon that does not act acting as the triggering user, the current user may be null, in which case you will need to so you must deal with it programmatically.

Scripts are executed within the issue context.

Return Codes For Post-Functions

return;

Note that “return;” ends the program, and any values returned by the script returns are ignored.

Order of the Post-functions

In general, it’s recommended to place post-functions after all standard post-functions. This allows the issue to be re-indexed and the data stored correctly.

The new issue has not been indexed if the post-function is applied to the “create” create transition. Also, the index does not exist until the index this step runs for the first time, and no data may exist for the issue. For these reasons, it is always best for the post-function to be come after all the standard post-functions.

As an example, we will reuse the above configuration example:

However, this time, let’s modify the post-function script to read:

logPrint("ERROR", "The status is :" + status); // such a simple script !!

When the issue is transitioning transitions from a state the “To Do“ state to the to the state “In Progress“ state:

The status is :To Do
The status is :In Progress

Notice that even if we are in the same transition, the status is not yet updated (it’s the next following action in the list of post-functions). The same may happen for custom fields or system fields, so it is recommended to always move the SIL post-functions to the last position in the chain!