Symptoms

We encountered some issue in our client's environment after deploying our solution packaged from our own environment. After doing some checking, we found that the rules that we configured in the source environment is missing in the destination environment. This is weird as we wouldn't be able to package the solution in the first place if the rule is not configured. Hence we suspect that somehow it's missing during the deployment?
 

Diagnoses

In the affected forms, the reference to some of the views might have been broken, which results in rule configurations going missing. There is most probably some error during package deployment.
 

Resolution

When opening the packages provided with the Package and Deployment tool, it was observed that the Views that caused the issue have conflicts with the red icon. The issue will appear if we select the "Use Existing Version" conflict resolution.

There are 2 icons to differentiate the severity of the conflicts, a yellow and a red icon. When artefacts have the red conflict icon, it usually means that the artefacts are in system conflict with the K2 environment. When faced with this conflict, if allowed, the best option is to deploy a new version of the artefact instead to use an existing version. User has been advised to select "Create new version" conflict resolution option when faced with this type of conflict in the future.

However, user noted that this issue still appears even if the Package and Deployment Tool does not indicate any red conflicts. After discussion with the user, we agreed that there is a possibility that earlier deployments may have encountered the red conflicts and the wrong conflict resolution has been selected. This may have broken the references in the destination environment and caused the rule configurations in the SmartForms to go missing.

The user has also noted that the forms and views may have been modified in the destination environment after deploying the packages exported from the source environment. The act of checking out forms/views then checking in is considered as logging a change in the form. Such modifications in the destination environment can cause discrepancies between the destination and source environment, and can directly result in more conflicts as new packages from the source environment are being deployed. User has been advised to refrain from making modifications directly in the destination environment. Any changes should instead be made in the source environment and then exported over to the destination environment when ready.