Bypass Validation Examples

When you configure a Column Change, Stored Procedure, or Web Service workflow in user initiated or scheduled workflows, the workflow will bypass any business rules and system validations that are programmed within DPS.

As a result of bypassing, some steps of a workflow cannot be completed automatically as they would normally be in the DPS application, so you must either create additional workflows to complete the omitted steps or manually complete the omitted steps in the appropriate DPS application. Two areas where bypassing occurs and you have to create additional workflows or complete manual entry are when records are associated across hubs and when fields are updated.

Associating Records Across Hubs

When you associate one hub record with another hub record, DPS automatically makes a complete association between the two records. For example, when you add a new contact for an employee on the Firms & Contacts tab in the Employees hub, the employee is also added as a team member for that contact on the Our Team tab in the Contacts hub. The two records are automatically associated across both the Contacts and Employees hubs and the association is reflected in both hubs. However, if you use a workflow to add a new contact for an employee, the update is one-way and the contact is added to the Firms & Contacts tab in the Employees hub, but the employee is not added to the Our Team tab in the Contacts hub. You must create a second workflow to have the employee automatically added to the Our Team tab in the Contacts hub, or you can manually add the employee in the Contacts hub.

For workflows that associate records across hubs, you must either build a number of workflows to complete each piece of this process or manually add the associated records in the other hub in which it was not automatically added.

Updating Fields

Similarly, there are many fields in DPS that are interdependent and, when you make a selection in one field, other fields will automatically update based on that selection. For example, if you are moving a project to the Won stage and your security role is for Accounting users, the Approved for Use in Processing option on the Accounting tab of the Projects form is selected automatically to indicate that accounting transactions can now be entered for the project. If you change the stage to a Lost or Do Not Pursue stage, the status of the project is automatically changed to Inactive. If the project has a linked promotional project, you are also given the options to change the status of the promotional project to Inactive or Dormant or to leave it with the Active status.

If you set up a DPS workflow to update a field that automatically updates additional fields, the workflow will only apply to the field that initiates the action. For example, if you change the Stage to Won based on a user-defined field, these automated validations, such as the selection of the Approved for Use in Processing check box on the Accounting tab of the Projects form, do not occur. You must manually set up a workflow to support each of the validations or manually select the option.