Package and Deployment Considerations

If you have a firewall with port restrictions within your company network, you must open outbound connectivity over a port range to ensure the Package and Deployment tool can connect from your company's network to your K2 Cloud environment. The port range is 25683 - 26707.

All packaging and deployment actions use the identity of the server service account. However, your credentials are validated to ensure you have the necessary permissions to package and deploy.

To create and deploy a package, ensure that you have the following rights and memberships in the source and target environments:

• Workflow Export Rights
• SmartObject Publish rights. A check is performed to validate if SmartObject Publish rights have been set on specific SmartObjects that have been generated in the application
• You are a member of the Package and Deployment role

When creating a workflow, remember that you are the owner of the workflow, and you need to enable sharing before other users can view or edit it.

To ensure a successful package and deployment, you must have View rights to all objects in the system. This ensures that when dependencies are checked, Package and Deployment can determine whether items exist (and need to be updated) or do not exist (and need to be created). The Package and Deployment role grants its members global view rights but membership in this role does not override any Deny rights you may have set for the identity currently packaging or deploying.

In some cases it is possible to deploy packages created in one Nintex product to a different Nintex product. The table below lists which cross-product deployment scenarios are possible.

The following table lists the artifacts that are included in or excluded from deployment packages. You can assume that anything not explicitly listed as "Included in Package?" in this table, is not included in the deployment package.

Artifacts included in the package are based on selections you make when creating the package. You may need to manually add or remove items from the package depending on the artifacts used in your application, however Package and Deployment is designed to include all dependent artifacts it can find.

Artifacts Not Included

Deployment packages include application artifacts such as SmartObjects, views, forms, and workflows. Deployment packages do not include third-party components or certain artifacts, including (but not limited to):

• SharePoint lists or libraries
• SharePoint items (e.g list items or documents)
• SharePoint fields, columns or content types
• Workflow reporting data
• External data stores such as SQL Server databases and tables

The table below describes some artifacts or scenarios that require special attention when using package and deployment.

SharePoint Considerations

1. For lists with managed metadata, you may have to manually fix the Term Store and Term Set GUIDs after deployment.
2. If you package an App where the SmartObject property is based on a taxonomy field (managed metadata), the Term Store and Term Set are not included in the package.
3. If you have a Referenced Item in a package and it already exists on the target environment at a higher site level (for example you are deploying a package to a subsite where the main site already has that artifact with a match), the auto-matching function preselects the main site artifact. If that artifact is not what your solution must map to, change the artifact in the Items Packaged By Reference section of the Additional References page by double clicking the artifact and selecting the correct artifact from the drop down list. This is only necessary when dealing with same site collection deployment.
4. Categories in SharePoint are updated when deploying across environments. For example, on the source environment (http://portal.denallix.com/), when you integrate the product with a list called “Sales”, your category structure resembles the following:
   
   • SharePoint
     • Portal.denallix.com
       • Lists
         • Sales
           • Sales SmartObject
           • Sales Form
           • Sales View
   On the target environment (http://sales.denallix.com/sites/main), when you deploy your package and rebind your list to “SalesX” your category structure resembles the following:
   
   • SharePoint
     • sales.denallix.com
       • Lists
         • SalesX
           • Sales SmartObject
           • Sales Form
           • Sales View
   • The artifact names still contain the original list's name
   • When clicking on your list ‘SalesX’ and then the application icon, the artifact page breadcrumb still show as the ‘Sales’ list, as this is based on the category name from the source environment
5. In certain scenarios when remapping to a list or library that does not match the definition in the source environment, the SharePoint fields show an error. You must cancel the deployment, fix the definition of the target list or library, and then try deploying the package again.
6. If you add multiple servers to the Package and Deployment console, ensure that all the servers are running the same version of the product.

7. When deploying a package to a target environment that has a new document library, deployment notifies you that the document library does not contain all the properties required for the solution to deploy. The following messages display:

   • Shared With (SharedWithUsers) Property is missing from the selected object
   • Shared With (Value) (SharedWithUsers_Value) Property is missing from the selected object

   This message is shown because SharePoint only adds the SharedWithUsers column to the document library after a document has been uploaded and shared.

   To resolve this issue:

   1. Navigate to the target document library.
   2. Upload a document.
   3. Share the document with someone.
   4. Delete the document.
   5. Click on the refresh button on the list or library remapping page.
   6. Select the target document library.

When you use the Navigate to option in a workflow Task SmartForm configuration as shown in the image below, the form URL in the current environment is used. When you use the Package and Deployment tool to migrate applications between environments, this URL is no longer valid in the new environment. If you’re planning to migrate the solution to another environment, we recommend using the Navigate to URL rule action instead to navigate to a SmartForm.

Follow the steps below to configure the Navigate to URL rule action:

1. In the Designer, edit the form used for the Task in your workflow, create a new rule and add the Navigate to a URL action.
   
2. Click configure to add the form URL to the action. You can get the form URL by clicking the Runtime link in the Browse section on the form’s properties page. Click OK.
   
3. This rule doesn’t have a rule event, so you can name the rule and click OK to save it.
4. Edit the configuration of the Open the Task Worklist Item rule action by clicking the configure link. The action is typically found in the When the Form is Initializing rule.
   
5. Select Call this Rule and select your new rule from the drop-down list. Click OK to save the configuration and OK to save the rule. Click Finish to save the form.
   
6. The option is automatically updated in the Task Form configuration in your workflow.
   

Known issue:
When you use a DocuSign template with any of the DocuSign workflow events, package and deploy your solution to a target environment containing a different DocuSign instance with different template GUIDs, and start a workflow instance of the workflow containing the event in the target environment, an error occurs. This is because Package and Deployment doesn’t support refactoring of Docusign templates.
Workaround:
Open the workflow in the target environment, reselect the correct template in the DocuSign workflow event, and deploy the workflow.