Dodeca Workflow

First things first.  Dodeca does not come with built in workflow or process management.

But what you CAN do is build process management, or workflow, into your Dodeca application.  And you can build it the way you want it, and it can be done relatively easily.  The key to this is that Dodeca is really an Application Platform for building the exact application that meets your requirements.

It is powerful and flexible.  Powerful because there is an incredible amount of functionality that can be added to your application.  Flexible because the functionality can be adapted to specific users and specific situations.

In this post, we will have a look at a sample application called Outlook.  This is a company forecast application that is used multiple times throughout the year.  It uses a version of the Sample Basic Essbase application.

The Outlook Application dashboard

This is going to be a basic example of Process Management that only involves the Submission and the Approval or Rejection of the entire scenario.  We will explore the use of Planning Unit Hierarchies in a later post.

We will use Roles in Dodeca for this example.  For more information on Roles in Dodeca, please see the previous posts:  Roles in Dodeca and More on Roles

We will continue with the Planner and Reviewer roles that were demonstrated in those posts.  As in the other post, I am using Andy Dwyer (userid = dwyera) as the test Planner, and Leslie Knope (userid = knopel) as the test Reviewer.

We will also use a relational table to hold information about the scenario status.  It is one table structured like this:

The Scenario table

So, we have our Essbase application, Dodeca and a single SQL table.  With only these ingredients, we can demonstrate a basic forecasting submission workflow.

As shown in this previous post, we have assigned View Hierarchies based on Roles.  Only users with the role of Planner will have access to the Views that allow data input.  Here are the Input Views:

The Input Views in the Outlook application

Roles are important in this process.  Here are the specific actions permissible by Role.

A Reviewer can:

  • Open a scenario for Input.  This action will notify (via email) the Planning team and open the scenario for input on the Planning Views.
  • Review a scenario.
  • Accept a Scenario that has been submitted.  This action will notify the Planning team of acceptance and prevent any more input.
  • Reject a Scenario that has been submitted.  This action will notify the Planning team and reopen the scenario for input.

A Planner can:

  • Enter input to an open Scenario.
  • Submit a Scenario to the Review team.  This action will notify the Review team that the scenario has been submitted and prevent any more input.

After data for a scenario has been entered, Planners can to the “Review, Submit, Accept” View to submit the scenario for review,  In an attempt to keep things simple, we will focus most of this post on this “Review, Submit, Accept” View.  This is where the majority of the process management functionality takes place.

The Review, Submit, Accept View

We have three buttons on the toolbar for this View and they are only enabled under certain conditions.

Process Management buttons on the View Toolbar

The Submit for Review button is enabled if:

  • User has role of Planner
  • Status of the Scenario is Open or ReOpened

The Accept Submission button is enabled if:

  • User has role Reviewer
  • Status of the Scenario is Submitted.

The Reject Submission button is enabled if:

  • User has role Reviewer
    Status of the Scenario is Submitted.

This is all controlled through the extensibility that Dodeca provides with Dodeca Workbook Scripts.  We will not look closely at workbook scripts in this post, since the purpose of the post is to provide an overview of possible functionality as opposed to step by step instructions.

The Workbook Script for the Review, Submit, Accept View

The buttons on the View toolbar are tied to specific functions in the Workbook script.  When a user clicks on the Submit for Review button, the actions (methods) defined within the Submit procedure will be performed.  If you would like more information on how a specific function is accomplished please let me know.

So let’s have a look at the Review, Submit, Accept View:

I am in the application as test user Andy Dwyer with a role of Planner, and the Status of the scenario is Open, so the Submit for Review button is enabled.  Once I hit submit, a few things happen.

1.       An email is sent to the Review team.  Here it is on my phone:

Email from Dodeca

(Quick note on testing user emails.  Jake Turrell has on post on setting up multiple email addresses with one Google Gmail account: Using Test email accounts.  I used that method here for testing multiple target emails.)

2.      The scenario is set to Submitted.  Since I am testing as a user with the role Planner, I cannot Accept or Reject the submission.  Those buttons are still not enabled.

All buttons disabled.

Now lets assume that Leslie Knope, as part of the Review Team, received the email and is eager to check it out.  She can open the application and go to the same View.  Since Leslie does have a role of Reviewer, and the status of the Scenario is Submitted, she will see the Accept and Reject buttons enabled.

Reviewer Buttons enabled

Something is not quite right, so she will reject the Submission.

Upon this action, the Status is set to Reopened.  And now, for Leslie, all three buttons are disabled because as a Reviewer, she cannot submit an Open or Reopened scenario.

When Leslie rejected the Submission, Andy, who is on the Planning team, received this email:

Email indicating Submission has been rejected

Andy was able to make some updates on the Planning input Views that increased the total year Profit margin and is ready to submit again.  When he opens the Review, Submit, Accept view, he will see his new totals and can Submit again.  Now Leslie can open the View and Accept the submission.

Once it is accepted, all three buttons are disabled for both Andy and Leslie as no further actions can take place until the Scenario is opened again during next year’s cycle.

So that’s it at a high level.  The goal of the post was simply to highlight some things that can be done in Dodeca for Process Management.  I did not want to delve into to specifics of updating the SQL table, sending the emails, setting the logic for enabling buttons, etc, but I certainly can describe those steps in more detail in a later post.

The key is that although Dodeca does not come with predefined workflow functionality, you can build it with Dodeca.  And it can be built the exact way you want it.

 

More on Dodeca Roles

This post will expand a bit on the last post regarding Roles in Dodeca.

Can a user have multiple Roles?

Yes, a user can be assigned to multiple roles.  Simply use the drop down in the User Manager to check all or any roles that are applicable.

Assign multiple roles for users

If the HierarchyToRole mapping is defined, what hierarchy is used if a user is not assigned to a role?

In the last post we saw how the user’s role determined the hierarchy that they are assigned in the application, but what if a user attempts to open the application without being assigned a role?

First thing to consider is the HierarchyID property.  In the example in the previous post, this property was empty.  But a HierarchyID could be defined here, for example Standard, and in that case, the it would be the Standard hierarchy that would be presented to the user.

No Default Hierarchy defined for Application

If there is no HierarchyID defined, then there are more Application property settings to consider for this situation.

From the last post, we updated the AuthenticationServiceObjectTypeID property to DodecaUserRoles, and we also set the HierarchyToRoleMapping property for our two roles: PLANNER and REVIEWER.

There is another Application property to consider under the Security section.  It is called AllowStartupForUserAssignedNoRoles.  The default for this property is set to True.

The AllowStartupForUserAssignedNoRoles property

This indicates that a user can still start the application even if they do not have a role assigned.  But since the hierarchies are only available to users with roles, and the HierarchyID property is blank, then a user with no roles will not see any hierarchy, as below.

Please note: the application has a DefaultViewId which is set to the view called Dashboard.  That view will open every time the application is started regardless of any role assigned.

No hierarchy

A better option may be to update the AllowStartupForUserAssignedNoRoles property.  We can set this to False.  We can then also update two other properties to provide relevant information to the user:

MessageCaptionForUserAssignedNoRoles – Set to “No Role Assigned”

MessageTextForUserAssignedNoRoles – Set to “You must have a Role assigned to start this application.  Please see your Administrator for more information.”

Message text for users with no assigned roles

Now when a user attempts to open this application it will not start, and they will be presented with the following message:

Message box for users attempting to start application with no Role assigned

Could there be separate Planner and Reviewer Applications, with User/Roles assigned to each?

Yes, if you would rather have totally separate Applications for Planners and Reviewers you could create them in the Application metadata editor and assign specific hierarchies to each.  In this case, you can specify role for startup using the RolesRequiredForStartup property.

Roles required for Startup

We can create a Planner application,  and you can assign one Hierarchy (Plan) for all instances of the application with the Default HierarchyID:

Assign the Plan hierarchy ID for the PLANNER application

Restrict Views and Categories within One Hierarchy using Roles

You and also use Roles to control specific Views and Categories within one defined Hierarchy.  In this case all users are using the same Hierarchy, but some Views or Categories of Views could be assigned for specific roles.  This is handled in the View Hierarchies metadata editor:

The View Hierarchies metadata editor

For a specific View or Category, you can set the AccessFilter property:

The AccessFilter property

The options are:

  1. None (the default)
  2. AnyRole – any user with any role
  3. AnySpecificRole – Users with a specific role, or a specific user
  4. AllSpecificRoles – Users with all the roles

Once the FilterAccess property is set, for example set to AnySpecifcRole, you can then set the AccessFilter_SpecificRoles property.  When you click on the ellipsis at the far right of this property, Dodeca will first check if there is more than one Smartclient application using roles, and if there is more than one, you will be asked to select which Application this will apply to.  In our example, we have a USER application, and a PLANNER application, so we are presented with the following:

Select the correct Smartclient application

In this case, I choose USER, and then I get the following dialogue to select the roles or specific users:

Select Roles and/or users

I can make multiple selections, one per line:

Multiple selections

Testing specific Users

Dodeca makes it easy to test specific users and their roles.  See the Application property in the Security section: AllowUserArgument.

The AllowUserArgument property

We can set this to true and then pass a User argument within the ClickOnce URL.  For testing the users in the USER application example I am using the following URLs to start the Dodeca application:

http://vmain1:8080/dodeca/smartclient/AppliedOLAP.Dodeca.SmartClient.application?t=OUTLOOK&a=USER&u=dwyera

http://vmain1:8080/dodeca/smartclient/AppliedOLAP.Dodeca.SmartClient.application?t=OUTLOOK&a=USER&u=knopel

You can see that in these URLs, the tenant (t=….) is OUTLOOK, the application (a=…) is USER and the user arguments (u=…) are dwyera and knopel respectively, for our two test users – Andy Dwyer and Leslie Knope.  This is how they appear in the User Manager:

The User Manager in Dodeca

Summary

As you can see, there is much power flexibility within Dodeca to use Roles to define the exact application for your specific needs.  Users can be assigned the proper roles, Applications can be tailored, and even access to specific Views can be managed the way you want them.

This power and flexibility is why we call Dodeca the Finance Accelerator!

 

 

 

Roles in Dodeca

Dodeca has built in support for Role definitions.  Once roles are defined, you can assign users to roles and allow role specific functions in your Dodeca application.  With the assignment of roles, you can do things like:

·         Allow access to applications

·         Control which Hierarchies are available to users

·         Allow access to Views within common hierarchies

·         Allow actions within workbook scripts based on roles

In this post we will run through an example of the second item in the above list.  We will perform the following tasks for a sample Dodeca application:

1.       Create 2 new roles: Planner and Reviewer

2.       Create 2 new hierarchies: Plan and Review

3.       Within the USER application, align the roles with the corresponding hierarchy.

Anyone who opens the application with the role of Reviewer will see the Review hierarchy, and anyone with the role of Planner will see the Plan hierarchy.

The OUTLOOK Application.

As the Admin, I have created the OUTLOOK Tenant and it has an ADMIN and a USER application.  It is a simple forecasting application based on the Sample Basic Essbase application that allows the company to build forecasts throughout the year.  The difference with Sample Basic is I have added a dimension for Years and have added additional scenarios to represent the forecast called Outlooks.

Here is a look at the View Hierarchy and opening View in the ADMIN application.  There are 13 views.

The OUTLOOK application

There are different functions in this application to performed by specific individuals.

A Reviewer can:

  1. Perform scenario maintenance such as: open and seed a scenario for data input, close a scenario and publish a scenario back to the Reporting Cube.
  2. Review input from Planners
  3. Accept or Reject the forecast from the Planners
  4. See all reports

A Planner can:

  1. Enter data on input forms.
  2. See some reports.

For our simple example, the activities translate into what can be performed in the Views.  We can control the activities of each role by controlling what views are available to each role.  Here is the list of View and the corresponding access by Role:

View Access by Role

Defining Roles

Roles are defined within your Tenant.  That is, they are available for use across any number of Applications defined in your Tenant.  In the OUTLOOK tenant, we have an ADMIN application and a USER application.  The roles and hierarchies in this example will apply to the USER application.

To define roles for the Tenant, go to User Roles under the Admin menu:

User Roles

This will open the User Roles metadata editor.

The User Roles metadata editor

We will create two new roles for this OUTLOOK Tenant: Planner and Reviewer. Click on the New button at the bottom of the editor to create the roles.

New role defined

Now we have two defined roles, REVIEWER and PLANNER.

New Roles defined in the Tenant

Next, we will create two new Hierarchies.  Go to the Hierarchies metadata editor from the Admin menu.

We currently only have the Standard Hierarchy, which we can see below.  We are going to create two new Hierarchies, and we will call them Review and Plan.  Hierarchies require and ID and a Name.

New Hierarchy defined

Once committed, the hierarchies will appear in alphabetical order, like this:

The new Hierarchies

Next, we can edit the Hierarchies to insert views and categories per the Access grid above.  Once the Views and Categories have been added to the hierarchies they will look like this:

New Hierarchies with Views and Categories

Great.  We now have the roles and hierarchies defined.  Our next step is to edit the USER application to set up the Role to Hierarchy mapping.

Open the Application metadata editor under the Admin menu, and click on the USER application:

The USER Application properties

The first property we need to update is under the Security category.  Update the AuthenticationServiceObjectTypeID to DodecaUserRoles.

The AuthenticationServiceObjectTypeID property

Next check the properties under the View Selector category.  Under ViewSelector Properties, there is a HierarchyToRoleMapping property.

The HierarchyToRoleMapping property

Click on the ellipsis on the far right to open the Hierarchy to Role mapping dialog box.  We set the mapping as:

Role to Hierarchy mapping

And save the application.

We have a couple of test users for this application.  Andy Dwyer is a Planner, and Leslie Knope is a Reviewer.  We can assign their roles in the User Manager in Dodeca:

Updating the Role assigned to Users

All done!  Let’s test the application for Andy:

The Planner Hierarchy

We see that Andy has the correct Hierarchy for a Planner.  Now let’s check Leslie:

The Reviewer Hierarchy

Yep, Leslie has the correct hierarchy for a Reviewer.  Voila!  All set!