Recently, one of our clients asked us if we could ensure that new vendors would not be available for use in transactions until a second user approved the vendor. While a custom script could achieve this task, a workflow would provide the simplest, most straightforward solution. Consequently, we set out to create a vendor approval workflow for this client.

Workflow Prep

If you’ve been following along with our workflow series, you know that the first step in creating a workflow is to brainstorm possible routes your workflow could take. After some discussion, we decided that the best solution would be automatically making new vendor records inactive when they are created. The workflow would then email the designated approver and provide an approve button on the vendor record. After the approver selects the approve button, the workflow will activate that vendor record, enabling the vendor to appear on transactions.

At several points throughout our workflow, we will need to reference the “approver” individual. We know who that approver will be for our client, and so we could easily reference that specific individual throughout the workflow. However, the more responsible long-term solution would be to create a workflow field for the approver. Then, whenever our workflow needs to reference the approver, we would reference the approver field rather than the specific individual. If a different employee ever needs to be the approver, one change would quickly update the approver throughout the workflow.

Our Workflow States

As this workflow is relatively straightforward, it will need only three states: initiation, pending approval, and approved. Let’s take a look at the major parts of each state.

Initiation

When we started our workflow, we determined that it would run on the vendor record. We also determined that it would be an event-based workflow that would trigger on Create. Therefore, the following actions will take place only within the context of a user creating a new vendor record.

Our initiation state has the following three actions:

  1. Set Field Value—This action populates the approver workflow field we just created with a specific employee. Whenever the approver changes, this action is all that would need to change. Because our approver needs to be in place right from the start, this action will trigger on Entry.
  2. Set Field Value—This action, which triggers on After Record Submit, designates that the field Inactive will be set to the static value of checked. As soon as we create a new vendor record, this action renders the entire record inactive.
  3. Send Email—This action, also triggering on After Record Submit, requests that the designated approver review and approve the new vendor. When creating this action, we selected the current user as the sender and the approver as the recipient. We also wrote a brief custom message and checked the Include View Record Link box. Consequently, the approver will have a quick way to jump right into the vendor record directly from the email.

And that’s it for our first state! Notice that we have two Set Field Value actions. There is no limit on how many actions you can include in any given state, and you can have multiples of the same type of action. Our transition from the Initiation state to the Pending Approval state is a simple one with no specific conditions in place. Just pull the transition line down from Initiation to Pending Approval, and you’re ready to move to the next state!

Pending Approval

The second state contains the following three actions:

  1. Set Field Value—This action triggers on Entry and checks the Inactive field.
  2. Add Button—This action adds the button “Approve Vendor” to the vendor record. We set a condition, however, that this button will appear only for the designated approver. This action triggers on Before Record Load.
  3. Set Field Display Type—This action, triggering on Before Record Load, sets the display type of the Inactive field to hidden. Our reasoning behind this action was simply that we didn’t want anyone other than the approver to be able to activate a new vendor record.

We set the transition between Pending Approval and Approved to execute on the Approve Vendor button. In other words, once the designated approver clicks the Approve Vendor button, the workflow automatically moves to the final state.

Approved

The final state of our vendor approval workflow has just one action: setting the value of the field Inactive to unchecked. Essentially, once the approver has approved the new vendor record, the record becomes active and is now accessible for use in transactions. We also checked Do Not Exit Workflow when we created this state. This setting ensures that the workflow will not restart on the same vendor record after the workflow has already run. The Approved state box represents that setting by a circle made up of two arrows.

Testing the Workflow

The last step in building a workflow is to test it. Does it behave the way we expected it to? To test our vendor approval workflow, we created a new vendor record. As we expected, after we created the vendor record, our workflow automatically inactivated it and created the Approve Vendor button. Clicking that button activated the record.

Conclusion

We hope that learning about our vendor approval workflow has been helpful for you! If you have ever come across this type of situation or if you have ideas for different ways to finagle this workflow, please drop a comment below. And don’t forget to subscribe to our mailing list so that you never miss out on our latest NetSuite blog posts!