NTX PowerShell Action - Stable Release

Userlevel 7
Badge +9

NTX PowerShell Action - Stable Release


  • Robust security features based on Windows Remote Management.
  • Ability to execute PowerShell scripts from any machine allowing Remote Management from your SharePoint servers.
  • PowerShell exceptions are handled so workflows are unaffected.
  • OpenSource
  • Actively Developed
  • Automated Installation Routine

Planned Features

  • Async PowerShell script execution
  • Script Repository
  • Run worker as a centralized SharePoint service instead of in Workflow Infrastructure
  • Pass SPServer object to PowerShell session for determining executing server.

Current roadmap/planned features can be found here.


Disclaimer: As stated in our Terms of Use, Nintex is not responsible for any third-party content made available for download on Nintex Connect, whether or not this content has been reviewed and/or moderated by Nintex and regardless of who originated that content (including, but not limited to, Nintex employees, partners, affiliates, or moderators).  Users shall assume all risks associated with applications and other content provided on Nintex Connect.  Nintex does not provide support for any content and plugins provided for download at communities.nintex.com.

NTX - Home

Source Code

Source Code (Archive)

Source Code on Github

Screen Shots



56 replies

Hi Aaron,

First, thanks for this project. It's just what i needing.

But I've two questions :

1. In the documentation you mention NTX.PowerShell.wsp but in the downloaded file is PSAdapter.wsp.  What is correct ?

2. I already wrote the script in a ps1 file. Can i call this script in the action or must i write all the code in  the configure action windows ?

Thanks for your reply.


Hi, I have installed this on our development environment and all is working OK. We have SP2013 on prem. However, on our production environment the workflow is returning an error when it gets to the PowerShell action.

Returns the following error:

Error executing PowerShell Unrecognized activity encountered: PS Activity.Activity.

Any ideas how to resolve?

Hi guys,

Here are the answers,

1. The correct file name is PSAdapter.wsp (from the download file). The installation works fine and it's very easy (Thanks to Aaron for that).

2. Yes you can call a script directly in the action. And as me, pass the variables, constants, etc... from the workflow as command line parameters of your script.

Have a nice day.


Userlevel 7
Badge +9

Not sure how I missed these questions (from you and Darren). Thanks for replying back with the answers!

Userlevel 7
Badge +9

Hi Darren,

I would try removing the action from the production environment and re-adding it. Note: You may need to delete the duplicate record from the Activities table in the Nintex Configuration database.

Did you run the install as the Farm Installation account? If not, I would recommend doing that as any other account may not have the necessary permissions to accomplish all of the things the script does.

Hope this helps!

Appears it was the scanner software! Its service needed re-starting after adding the powershell action and allowing on the web app.

I believe due the scanner software set up having a ref in it's config file to the web app.

Userlevel 7
Badge +9

Ahhhhh okay, thanks for the update! Let us know if you run into any other hiccups.

Hi Eric,

Iam basically stuck at the same Problem. My script runs fine directly on the Server, but once i try executing it from the NTX-Action i get no result back.

I know the powershell-action basically works (tried it with a simple Get-Random and got a value back).

Did you make any progress in solving the problem?



Hello everyone,

I ran the installer and made sure my scenario matched the install requirements. However, I do not see the powershell action. I tried to look for it in our manage allowed actions but I don't see it there either. Am I missing something?

Hi William,

Have you ran the installation as SP Farm Administrator ?

I had the same problem, because the first time I had ran as site collection administrator, but it is not enough.

Thanks for that great Tool. I have used that in Nintex 2013. Works that also with Nintex Workflow 2016 and Sharepoint 2016?

Have some experiance with that?


Does this work in Office365?  If not, are you aware of any PowerShell Actions that would work in Office365?

Hi Aaron,

great idea to create PowerShell action for Nintex.

I have a question. How can I pass the workflow variables to this action?

Nintex does not have a inline function for strings to be URL encoced, thus provides to use this action.

I wrote this script below unfortunately, I can not pass a workflow variable to Powershell variable.

[string]$inputString = {WorkflowVariable:inputString}

if (![string]::IsNullOrEmpty($inputString)){
    function htmlEncode{
        $encodedInputString= [System.Web.HttpUtility]::UrlEncode($inputString)
        return $encodedInputString
    function htmlEncode{
        return "Input value is empty!!!"

Any Ideas?

Userlevel 7
Badge +9

Hey Eric,

It does not work in O365 as of yet. This could be written however, you would need to deploy some bits to an Azure subscription.


Userlevel 7
Badge +9

It is not compiled for any platform but 2013 at the moment.

Userlevel 7
Badge +9

You should be able to use variables in your PowerShell scripts. try output $inputString, does it spit anything out in the return value?

Additionally, you might consider using this web service with the Web Request action instead: http://aaronlabiosa.com/url-encode-decode-rest-endpoint/

Hi Aaaron,

thanks for the quick response and for the link. Web service for URL encoding is also an option. Nevertheless, I would like have this PowerShell Action functional because it offers many other options for use.

Look at my test workflow, maybe something I'm doing wrong.

There are four actions:
1)      Set variable as "Hello world!!!"
2)      PowerShell action (actually only for testing input variable)
3)      Log in History List to log output variable "powerShellOutput" in workflow History
4)      Send notification to get output variable in e-mail


When I tried to define PowerShell variable $inputString inside in PowerShell action, it returned me value to Result Output variable "powerShellOutput".

[string]$inputString= "Hello world!!!"

function htmlEncode{

    return $inputString




When I tried to pass workflow variable "{WorkflowVariable:inputString}" to PowerShell variable "$inputString" it returned me blank row (as you can see quotes at the picture) to Result Output variable "powerShellOutput".

[string]$inputString= {WorkflowVariable:inputString}

function htmlEncode{

    return $inputString




Am I doing something wrong?

OK, I found my mistake.

Workflow variable needs to be closed in quotes [string]$inputString = "{WorkflowVariable:inputString}".


Userlevel 7
Badge +9

You might try running that code in a WinRM session instead of right in the action. A WinRM session should emulate what the action does on the back end.



I have successfully deployed the custom action on SharePoint 2016 with Nintex Workflow 2016, but I cannot seem to activate it to more than one web application. Is there something within Nintex that I am not doing right? I am certain this action should work on every web application in my farm, not just one!

Has anyone had issues with the 'SSL Enabled' button not stay staying checked? When saving action the SSL Enabled button does not stay checked.

Userlevel 7
Badge +9

Hi Michelle,

The action was not compiled for SharePoint2016 (unless someone has forked the project). The fact that the action works at all on 2016 is fairly impressive in my opinion! Is the one Web Application that it functions on one that was migrated from SharePoint 2013 by chance?


Userlevel 7
Badge +9

You could open a bug on the codeplex project site for this.

Yes. It does take a few saves for it to stay. I have seen this, too.

Yes, Aaron. The web application that works contains site collections in a content database created natively in SharePoint 2016. The place it is not working is a site collection in a content database upgraded from SharePoint 2013. I have checked to make sure the site collection/content database does not require upgrade. Does the fact that this was an upgraded database make a difference?