Administrator Guide - Part 1 – Kepion Support Center

Administrator Overview

The Administrator tab is designed for easy management of application security and workflow. You can access the administration page by selecting the ADMINISTRATOR node from the navigation pane.

Workflows are the unit of workflow within an application. Workflows are used to control data updates to the application for a given user base over a specified frame of time. When a workflow is available, users associated with the workflow can perform common workflow tasks such as submit, approve, and reject.

Create Workflow

To create a workflow, the Administrator first needs to create a workflow authorization. The workflow authorization will define a set of Contributors who will provide data for the workflow. Optionally, the Administrator can appoint a set of Approvers and Reviewers who can approve or review the workflow.

Workflow Contributors can use the authorized Forms to enter data by submitting one or more plans during a given time frame. Typically, one Contributor needs to make at least one submission to contribute to the workflow. However, it's also possible for the Contributor to make multiple submissions to their workflow during the time frame that the workflow is active.

If there are Approvers appointed for the workflow, then all the workflow submissions needs to be approved before any data is written to the data model.

Note: For the case where Post is enabled on the workflow, any Post action will immediately apply workflow updates to the data model. More information on the effects of the Post action is found in the Workflow States section.

A workflow is final when it is either approved or when the workflow authorization does not require an approval and has been submitted. Workflow submissions are not changeable after they're made final. The data model can only be changed then by new workflow submissions.

The workflow is closed when the workflow authorization time-frame has expired. It is also possible to lock down a workflow before the authorization expires by using the Lock action. More information on the lock action can be found in the Workflow Configuration section.

Workflow States

Kepion allows for complex workflow transitions. These transitions are pre-defined and allow the workflow to enter into the following states.

SAVED: The SAVED state specifies that the workflow is saved to the application and is available for the Contributor to restart the workflow from its last saved state. Saved plans are private to the user who initially saved the plan. Approvers and Reviewers typically do not see the workflow in a saved state except for the situation with saved posts. Should a workflow have posts, then it can be reviewed by Reviewers of the plan.

SUBMITTED: If the workflow authorization has Approvers appointed, then the workflow will need to be approved. The SUBMITTED state indicates the workflow is submitted and awaiting approval by an Approver of the plan. Submitted plans can be recalled, re-submitted, rejected, and approved.

If there are no Approvers for the plan, then the SUBMITTED workflow is in the final state for the workflow submission.

REJECTED: The REJECTED state indicates that the Approver rejected the changes contained within the plan. Rejected plans needs to be re-submitted.

APPROVED: When a workflow is approved no further action is available to it and the workflow submission enters into the final state. Any additional changes to the data model will need to be made through a separate workflow submission.

Workflow Actions

For each workflow state, there are various workflow actions that are available for the user to invoke. Here is a summary of what each action will do.

Save: This action saves the current changes made on the workflow to the application. A saved workflow can be re-opened at a later point in time to continue working off the plan. Saves are private to the user who initially saved the plan.

Submit: The submit action is used to finalize the changes made to the workflow by the Contributor. By submitting, the Contributor is indicating that the changes are ready for approval. If there is no Approver for the workflow authorization then no approval is needed. In this case the submit action will result in an update to the data model and the workflow submission is complete.

Discard: The discard action can be invoked to remove the workflow submission from the workflow process. Once discarded, workflow submissions can no longer be accessed by users. The discard action is available when the workflow is not final. Only the plan’s originator and Approver can discard the workflow submission.

Recall: The recall action can be invoked in order to pull back a submitted workflow before an Approver has the chance to approve it. Choose to recall the workflow when you need to make additional updates but you have already submitted the workflow for approval. Recalled plans will enter into the saved state and not be available for review or approval. When a workflow with Approver(s) is in the final state, for example when all Approver(s) have approved, then the recall action will no longer be made available for the Contributor. In the scenario where there are no Approver(s) for the plan, the Contributor submitting the workflow will have access to the recall action.

Reject: An Approver can use the reject action to reject a workflow submission. Rejected plans can be re-submitted to the approval process.

Approve: The approve action can be performed by an Approver to send the workflow into the approved state. Once a workflow is approved, no further workflow actions can be applied.

Comment: Reviewers have the ability to use the comment action to add in their review notes during a planning process. The comment action does not change the state of the plan. This action is only available for Reviewers.

Post: The post action allows Contributors and Approvers to apply workflow updates immediately into the data model.

Common Workflow Cycle

Scenario 1 – Basic Contributor and Approver Process

Contributor starts new workflow submission and makes updates.
Contributor finishes workflow updates and invokes workflow action Submit.
If there is no specific approval chain configured for the user, user chooses one of the Approvers to send workflow to. Otherwise, the workflow will be sent to all Approvers.
Approver sees the submitted workflow from contributor on the APPROVER tab within Apps
Approver opens workflow submission and reviews information.
Approver invokes workflow action Approve to finalize the workflow submission.

Scenario 2 – Contributor Private Saves

Contributor starts new workflow submission and makes updates.
Contributor saves workflow and closes browser.
Contributor views Apps page and see previously saved plan.
Contributor restarts plan.

Scenario 3 – Re-Submitting a Rejected Plan

Contributor starts new workflow submission and makes updates.
Contributor finishes workflow updates and invokes workflow action.
User picks Approver to send workflow to.
Approver sees user’s workflow from on the APPROVER tab within Apps.
Approver opens workflow submission and reviews information.
Approver invokes workflow action Reject.
Contributor refreshes Apps page and sees rejected plan.
Contributor opens and updates the rejected workflow submission.
Contributor invokes Submit action to send the workflow submission back for approval.
Approver sees user’s updated workflow submission from on the APPROVER tab within Apps
Approver opens workflow submission and reviews information.
Approver invokes workflow action Approve to finalize the workflow submission.

Workflow State Diagram

Below is a state diagram showing the transitions from each of the STATES based on the actions that can be invoked from that STATE. Note that this scenario covers a workflow authorization that requires approval, and does not have Reviewers.