The App User Advanced Guide covers additional features and functionality reserved for experienced app users and/or complex app setups.
This guide covers:
Note: Please review the App User Guide before continuing. It covers the basic features and functionality all app users should know.
Workflow Roles and Actions
Kepion workflows refer to the process in which app instances are submitted, reviewed, and approved. Apps configured with the Advanced workflow type can have users assigned to different roles and stages of a workflow.
There are three workflow roles, each with its own responsibilities:
Contributors update data in app instances and submit changes for review and/or approval. All app users in the Basic workflow type are contributors.
Reviewers comment on submitted app instances but do not decide whether submissions are approved or rejected.
Approvers approve or reject submitted app instances.
In addition to the standard app actions, each role comes with unique workflow actions, which can be found when you open an app instance and expand the action menu.
The following sections explain the workflow roles and actions in more depth.
Contributors update data in app instances and submit them for review.
In the Apps module, go to the Home tab to view the apps for which you are a contributor.
Submit is used to finalize the contributor's changes made to an app instance. By submitting, the contributor indicates the changes are ready for approval. If there is no approver in the workflow, no approval is needed.
Contributors should use a unique, descriptive, and relevant name for the app instance. They can also write comments to provide information.
If approval is required for the app instance, the user will submit it to approvers. If an app instance is rejected, the contributor will need to re-submit the app instance again for it to be available for approval again.
Once the app instance has been submitted, contributors can discard or recall the app instance.
Discard deletes an app instance. Only the contributor and approvers of an app instance can discard it.
Recall allows contributors to revoke submitted app instances only before an approver approves/rejects them. Recalled app instances will enter into a saved state, preventing review or approval until it has been re-submitted. If there is no approval required on the app instance, this action will not be available.
Reviewers can review submitted app instances and add feedback to a submitted app instance.
Note: Users in this role cannot be added to approval chains.
In the Apps module, go to the Review tab to view the app instances available for your review.
You will see app instances you have been assigned to in the right pane.
The read-only versions of app instances allow you to preview the data without having to wait for contributors to submit their app instances.
Comment allows reviewers to add feedback to submitted app instances any time before they receive final approval. This action does not change the state of the app instance.
Reviewers can add their feedback to the Comments field.
Approvers are the final gatekeepers for any submitted app instances. They can approve or reject submissions.
In the Apps module, go to the Approve tab to view app instances available for your approval.
Note: A user can be assigned different workflow roles depending on the app or even multiple workflow roles for the same app. Learn more.
Tip: The progress chevrons represent the stages of the approval chain. You can hover over a chevron to see the username and their latest action.
Approve changes the app instance to the approved state or passes the app instance to the next stage of approvers. All approvers in a stage must approve the app instance before it can proceed. Once an app instance receives final approval, no further workflow actions can be applied to the approved app Instance.
Reject sends back the submitted app instance to the contributor. Rejected app instances can be re-submitted but will start back at the beginning of the approval chain.
Cell details show the properties of a data cell. To view this information, right-click a cell and select View cell details.
Here is an example of the window and its fields:
|The value of the cell.
|The formula of the cell.
|The comment stored within the cell.
|Checks if all the members are on the lowest level of the hierarchy. If this is FALSE, use the Slice information below to investigate further.
|Checks if the user has permission to write to the model and dimension to which the cell is linked.
Checks if all the members that define the cell have their Input attribute set to 1.
Checks if any of the members have their Annotation attribute set to 1.
|Indicates whether the cell is locked or not. This property is determined by the app lock option, which is located in Dashboard App configuration.
|The dimension and dimension member that define the cell. The value is the MemberId of the dimension member.
Tip: If a cell is not editable, refer to this article for troubleshooting steps.
Drill-through (Transactional) allows you to drill through the data in the transactional database.
You can perform a drill-through on a form only when your app's designer has defined a transactional drill-through for the form.
Tip: Refer to this article for instructions on configuring transactional drill-throughs.
If these two criteria are met, right-click on any data cell in the form and select Drill-through (Transactional).
The Source tab lists all the available drill-through definitions available for the form.
Select a source and then Run. You will be taken to the Results tab.
Export allows you to save the results as a .csv file to your local machine. You can also return to the Source tab to perform another transactional drill-through.