Approval Sequences FAQs

Is the Submit action with the reason / approval tree intended to replace steps?

The Submit action is not intended to and cannot replace workflow steps. Instead, the Submit action works in conjunction with Steps to simplify commerce workflow. The Submit action abstracts the reason and approvers tree from the workflow so that the FullAccess user is able to maintain approval sequences independent of Participant Profiles. In addition, the approval sequence is available to the admin in a graphical format that is easy to maintain. This is useful for the following:

• Decouple approval login and approvers from steps, reducing the number of steps needed in the workflow
• Decouples notifications sent to approvers from notifications sent during step transitions, reducing the number of transition rules
• Makes workflows easier to manage and maintain
• Provides a graphical tool for approval management

Steps and the Submit action perform related but different functions. While the Submit action determines the reasons for approvals and the approvers for each reason, steps provide document views.

• Use Steps to:
  • Provide Document View by Participant Profile
  • Define Transition Rules to change the document status
• Use the Submit action to:
  • Define reasons for approval along with the logic that triggers reasons
  • Define list of approvers for each reason along with the logic that trigger approvers
  • Control notifications sent to approvers

What action is performed when the user clicks Submit? What action is performed when the approver clicks the Approve/Reject Icon?

• Submit action: This action is performed in two different ways:
  • The submitter clicks on this action and there are no reasons to have an approver. In this case, the Submit action is performed without the transaction having to go through the approval process.
  • The final approver clicks the Approve icon and there are no more reasons to approve. In this case, when all approvals are done, then the Submit action is invoked automatically after the final Approve action.
• Revise Action: This action is performed when the user clicks the Revise Action.
• Request Approval: This action is performed automatically when the user clicks the Submit action and there are reasons to approve.
• Approve: This action is performed when the approver clicks on the Approve icon of the My Approval attribute.
• Reject: This action is performed when the approver clicks the Reject icon of the My Approval attribute.

With the quote in the Approved step, when the user clicked 'Revise', the quote did not appear to transition back to the Pending step.

How can Submit and its child actions be displayed on the transaction?

The Submit action and its corresponding Revise actions are the only actions that can be displayed on the Transaction page to the end user. Approve/Reject and Request Approval actions cannot be displayed independently on the UI and are triggered incidentally.

• Submit Action: This action is displayed on the Transaction page, provided that the current user has been given access to this action in the appropriate Participant Profile.
• Revise Action: Similar to Submit action.
• Request Approval: This action is performed automatically when the user clicks on the Submit action and there are reasons to approve.
• Approve: This action is performed when the approver clicks the Approve icon on the My Approval attribute. The FullAccess user can control the display of the My Approval attribute through Participant Profiles and must make sure that all approvers are given access to this attribute.
• Reject: This action is performed when the approver clicks the Reject icon of the My Approval attribute. The FullAccess user can control the display of the My Approval attribute through Participant Profiles and must make sure that all approvers are given access to this attribute.

Can a transaction have multiple Submit actions?

Yes. A transaction can have multiple submit actions and can simultaneously go through multiple approval processes related to each Submit action.

How are Standard Approval Notifications different from other notifications in Commerce?

Approval Sequences	Transition Rules
Notifications are sent for the following:  Pending Approval Notification: Sent to an approver when the approval becomes active. Retraction Notification: Sent to approvers when a reason is reset and approvers are no longer need to approve. Rejection Notification: Sent to the submitter when a reason has been rejected. Final Approval Notification: Sent to the submitter when the transaction is approved. Final Rejection Notification: Sent to the submitter when the transaction is rejected.	Sent only on step transition.
Most approval notifications are not customizable. See the topic Email Templates Overview and its associated topics to customize pending approval notifications.	Completely customized by the FullAccess user.
Customized modifications written in BML.	NO BML access. Only smart tags are available to allow dynamic values in email.
Special attributes available based on Email Templates or by using BML to customize a notifications.	Special attributes available in smart tags:  Document Link Submitted by

Related Topics

See Also