This project is read-only.

Execute PowerShell Script Nintex Workflow Action

The “Execute PowerShell Script” action allows you to execute PowerShell scripts from within Nintex Workflow 2010 workflows.

This is a custom Nintex workflow action based on Christian Glessners’ Execute PowerShell Script Action which is part of his Advanced Workflow Actions for SharePoint Designer 2010 which you can find also on CodePlex.

Please see the Documentation section for the installation instructions.

1.  Drag the “NintexCustomWFActionsExecutePowerShell” Action on to your workflow. By default it is in the “Custom” group.

Workflow Action 

2.    Configuration



The PowerShell script to execute. You can use the following predefined variables:

  $site = the current Microft.SharePoint.SPSite

  $web = the current Microft.SharePoint.SPWeb

  $list = the current Microft.SharePoint.SPList (null in site workflows)

  $item= the current Microft.SharePoint.SPListItem (null in site workflows)

  $ctx = the current workflow context Microsoft.SharePoint.WorkflowActions.WorkflowContext

  $sharePointService = the current Microsoft.SharePoint.Workflow.ISharePointService service

  $listItemService = the curent Microsoft.SharePoint.Workflow.IListItemService service

The process will run as system account. However, by default $site and $web will run as the current workflow initiator or author (impersonation step). When you want to impersonate the site to the system account create a site like this: $impersonatedSite = new-object Microsoft.SharePoint.SPSite($site.Id).

Avoid the usage of the SharePoint Designer Text Editor tokens in the script, because of the potential risk for script injection attacks. Instead use variable binding ($var1, $var2…)


By default every script that you want to execute must be digitally signed. However, you can change the setting to not require a digital signature (dev system). The corresponding PowerShell script is included in package. You can find the scripts in the nintexcustomwfactions\Activities\scripts folder.

Disable Script Signing

The script must run on a SharePoint machine

PS> & .\Set-PowerActivityScriptSigning.ps1 $false

Sign Scripts

In order to sign scripts you need the private key that has been generated during the installation of solution.

1. Export Private Key

The script must run on a SharePoint machine. Keep the private key secure.

PS> & .\Export-Key.ps1 –path “C:\private.key” –includePrivateKey $true

2. Sign the Script

After you have exported the private key you can sign the script. The signing must not be done on a SharePoint machine, you only need the private key and the script. To sign the script you have to save it temporarily to a file.

PS> & .\Sign-PowerActivityScript.ps1 –keyPath “C:\private.key” –scriptPath “C:\script.ps1”

The signature will look like this:


Simply copy & paste the script and the signature to the script and signature field of the “Execute PowerShell Script” action.

White spaces in the script will be ignored in the signing process.

$var1, $var2, $var3, $var4, $var5

You can bind PowerShell variables ($var1, $var2…) to workflow variables.

$web.Title = $var1


The binding is two way, this means you can change the workflow variables in the script.

$var2 = “my value”


$secure is a special variable that can contain an encrypted string that will be decrypted during runtime. You could use this variable to securely store a password. The binding of this variable is one way, means you can not set the value in the script during runtime. For how to encrypt strings read this.

Secure Store AppId

The Secure Store App have to define 2 Fields. One of type “User Name” and one of type “Password”. The Field Name doesn’t matter, important is the Field Type! You have to map the credentials of the SharePoint Service Accounts (AppPool/owstimer.exe). The secure store option will only works with SharePoint Server, not with Foundation! You can access the credentials during runtime with the $credential variable (System.Net.NetworkCredentials).

Notes and Warnings

The ‘Run Now’ feature is a bit kludgy at the moment. I’m still waiting to hear how to implement something similar to AddContextDataToString to get token replacement working.

Warning: As it is right now, it is possible to do script injection e.g. have a workflow variable contain any PowerShell script and execute it. I chose to go this route as it makes the scripts more flexible, we review all of the scripts that go in to our production environment and the script executes in the workflow initiator context so it can only do what the initiator can do. That being said, they could still do something like the following and run under the system account:

$impersonatedSite = new-object Microsoft.SharePoint.SPSite($site.Id)

But once again, we review all scripts that go in to production so we can check for script injection and the like. 

Last edited Jan 16, 2015 at 5:32 PM by ehalsey, version 4