We're updating some of our product names. K2 Five is now Nintex Automation. You may see both product names in our help pages while we make this change.

Permissions for installing Nintex Automation in an on-premises SharePoint Environment

From Nintex Automation 5.7 onwards there are two different apps for SharePoint. The legacy Nintex K2 for SharePoint: used for SharePoint on-premises and upgraded environments for SharePoint Online, and Nintex Automation for SharePoint: used on new installations for SharePoint Online.

This topic details the permissions needed to successfully install the product and use the Nintex K2 for SharePoint App in an on-prem SharePoint environment.

It is important to use different accounts to install and design the system applications using Nintex K2 for SharePoint. Using the same account may cause issues due to invalid security tokens.
When using the Nintex K2 for SharePoint App, use an account other than the Service account. Using the service account results in the SharePoint App user being used for all actions in SharePoint. If the Service account is the Administrator, use a different user than the Service account.

Local admin, as the AppDeployment.exe application in the setup folder requires this.
Site Collection Administrator / Contributor on the required App catalog sites to view and deploy to the catalogs.
To execute any SharePoint PowerShell command against a resource (where the resource is a Service Application or site / web application etc.) you need to be a member of SPShelladmin DB role on that resource’s database.
SharePoint_Shell_Access role, as the user requires permissions to execute the PowerShell cmdlet from the TechNet article:
- http://technet.microsoft.com/en-us/library/ff607596(v=office.15).aspx
- $contentDBId = (Get-SPDatabase | ?{$_.Name -eq "WSS_Portal"})
- Add-SPShellAdmin -UserName {DOMAIN\UserName} -database $contentDBId
  - When you run this cmdlet to add a user to the SharePoint_Shell_Access role, you must have membership in the securityadmin fixed server role on the SQL Server instance, membership in the db_owner fixed database role on all affected databases, and local administrative permission on the local computer.
    This cmdlet is intended only to be used with a database that uses Windows authentication. There is no need to use this cmdlet for databases that use SQL authentication; in fact, doing so may result in an error message.
  - In order to use Windows PowerShell 3.0 for SharePoint 2013, a user must be a member of the SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG local group on the computer where SharePoint 2013 is installed. However, the result of running this cmdlet is that the user specified with the UserName parameter will have the db_owner role access on the affected databases as described below. Therefore, you should carefully plan which users are given this access.
- Running this script results in the following database roles:
  - Content_database (On a Denallix system this database is called WSS_Portal and refers to the content database for the Portal Web application)
    - Public
    - SharePoint_Shell_Access
    - SPDataAccess
  - SharePoint_AdminContent_[Guid]
    - Public
    - SharePoint_Shell_Access
    - SPDataAccess
  - SharePoint_Config
    - Public
    - SharePoint_Shell_Access
    - SPDataAccess
    For more information on adding the App to a SharePoint Site and running it, see the Application Permissions in SharePoint topic in the Nintex K2 for SharePoint User Guide.