Help Center>Foundation Help

Applies to:

  • Winshuttle Foundation

Preparation and Account Requirements

The following sections include information about how to prepare for your Winshuttle Workflow installation, including system requirements, development server, authentication, and accounts details.

On this page:

Important: Depending upon the environment and configuration for which Winshuttle Workflow is being installed, additional steps may be required to get your Winshuttle environment configured and functioning properly. Please see the Workflow FAQ for a list of common problems and solutions.

Using a Development Server

Back to top

To minimize the risk of disruption and data loss, Winshuttle strongly recommend installing SharePoint and Winshuttle Workflow on a development (i.e. non-production) server first. Because the development server simulates a server in a real work environment (but operates in isolation), you can create, test, and refine your processes before moving them onto a production server. When you are ready to move to the production server, specify the URL of the production server within Winshuttle Workflow, and publish your workflows and/or forms to that server.

Authentication

Back to top

Winshuttle Workflow requires authentication to access a database and impersonate a system user with sufficient privileges to access the SharePoint Object Model. This is in addition to normal user authentication during SharePoint login.

To give Winshuttle Workflow the authentication it requires, there are two options:

  • SharePoint Object Model Access, which requires Windows authentication.
  • SQL Server Access, which requires either Windows authentication or SQL Server authentication.

Required accounts

Back to top

To deploy Winshuttle Workflow, you will need to provide credentials for a minimum of 2 accounts, and 1 email address.

The accounts you will require are as follows:

  • Workflow Admin Account: Communicates with SharePoint and runs the Workflow Central Administration site.
  • Workflow Database Account: Manages the Workflow database.
  • (Optional) Workflow Service Account: This account can be used to run SVservice.

    Note: SQL Aliases are currently not supported

The following tables provide a summary of accounts and required permissions.

Workflow Admin Account & Workflow Service Account

Back to top

Database

SQL Role

Stored Procedure

Stored Procedure Access

SharePoint Content Database

Public, db_datareader

All Procedures

Execute

SharePoint Configuration Database

Public, WSS_Content_Application_Pools

None

NA

Winshuttle Workflow Database (ShareVis)

None

None

NA

Note: If you are using (or plan to use) the Launch Form plugin, the Workflow Admin account must also have update permissions for the SharePoint Content Database (in addition to the permissions listed in the table above).

Workflow Database Account

Back to top

Database

SQL Role

Stored Procedure

Stored Procedure Access

SharePoint Content Database

Public, db_datareader

None

NA

SharePoint Configuration Database

Public, WSS_Content_Application_Pools

None

NA

Winshuttle Workflow Database (ShareVis)

None

All Procedures

Execute

Minimum SharePoint Server Access

Back to top

Domain Account

Local server groups

SharePoint Access

Winshuttle Workflow Admin account

Administrators

wss_admin_wpg

wss_wpg

  • Owner group at the root site
  • Owner group for the site collection that contains Workflow sites

-or-

  • Site Collection Administrator for root site
  • Site collection administrator for the site collection that contains Workflow sites.

Winshuttle Workflow Service account

Administrators

 

Site Collection Administrator

Winshuttle Workflow Database Account

None

None

Additional considerations for Winshuttle Designer

Back to top

In Designer (under Manage Mapping):

  • Web services will run as the "Logged in Window Account" or "Specified Account" as configured under Manage Mapping.
  • For the SSO setting, the web service cannot be run on "Form Load" as the password field gets removed on Form Load.
  • If a user has checked Use SAP Credential, the web service cannot be run on Form Load because the password field gets removed on Form Load.
  • Password fields are never saved.
  • Winshuttle Update plugin will not work with SSO and "Use SAP Credentials" configurations.

Autopost

The following are some minimal requirements and behaviors for Autopost:

  • User should have a valid Transaction License.
  • For System post: The person must be configured in Central Administrator
  • Note that the creator’s credentials are being taken into consideration and not the reviewer’s, for one-step or Two step review autopost.

Winshuttle Update

For Winshuttle Update:

  • Workflow will run this under the identity of the Workflow Administrator.
  • The SAP credentials of the user should be provided as displayed on the Central site.

Publishing a workflow

  • To publish a workflow, the user should have Full Control rights.
  • To access a site, route a workflow, or complete an activity, a user should have minimal Contribute rights.

Approving, Rejecting, or Completing a task

To approve, reject, or complete a task, a user should have Read permissions on the site.

SAP Lookup and Document Upload

The following are the authorizations and license requirements to use and Document Upload features:

  • A user should have a Central license.
  • RFC Authorizations:
    • For the S_RFC authorization object, the BDS_BAPI value is required.
    • Access to object S_BDS_DS is required with all values except lock and delete.
    • For document upload through Workflow, BDS_BUSINESSDOCUMENT_CREA_TAB BDS_BAPI and SWFMOD_F4_DTEL_GET_VALUES_TXT SWFMOD_WORKFLOW.
    • For Date fields to be changed in forms, the user must be authorized to SU3.