Organizational Chart Function

Introduction

Configuration

Access Platform Org Chart

DragOnce Org Chart is a native function on the platform. To access the Platform Org Chart, follow the below steps:

1. Open the Admin Panel and go to the Organizational Unit (OU).

2. All applications and all environments under a subscriber refer to the same org chart configured in Admin Panel.

Setup OU

To set up the OU, the below rules should be followed:

1. Org chart and OU can be configured by manual update or Excel template import

2. The highest OU level is 1, the lowest is 99

3. Every OU level can have multiple OU

4. Each OU can only be designated under one upper OU

5. Once created, an OU CANNOT be deleted

6. After setting up an OU, can assign users to OU Roles in the OU

   1. • Creation of OU and assigning users to OU Roles can be performed in the same Excel import

About OU Roles

1. OU Roles are separated from User Groups and Run Time User Roles, for grouping users into role(s) corresponding to their real life position in an OU

2. The primary purpose of OU Roles is for defining stakeholders in a Workflow State, by appointing user in OU Role(s) as reviewer(s) according to latest review status and Workflow Edge settings

3. Four OU Roles are available in every OU:

• Member

• Secretary

• Deputy Head

• Head

4. The names of the OU Roles cannot be changed

5. User cannot create new OU Role in the platform org chart

6. An user must be assigned at least one of either OU Roles (Member, OU Secretary, OU Deputy Head and/or OU Head) to be part of the OU

7. OU Roles can also be selected as user groups in User Picker widget, which Picker Type is Group or User and Group

The setting is explained as follows:

• (OU Name): grouping of all OU Members users in the OU

• (OU Name) [Head]: grouping of all OU Head users in the OU

• (OU Name) [Deputy Head]: grouping of all OU Deputy Head users in the OU

• (OU Name) [Secretary]: grouping of all OU Secretary users in the OU

• (OU Name) [All Users]: storing user groups:

  • • (OU Name)

    • (OU Name) [Head] 

    • (OU Name) [Deputy Head] 

    • (OU Name) [Deputy Secretary]

• (OU Name) [incld. lower OU]: storing user groups:

  • • (OU Name) [All Users] of the current OU

    • (OU Name) [incld. lower OU] of the immediate lower OU

If there is no lower OU, the user group (OU Name) [incld. lower OU] will only store user group: 

• (OU Name) [All Users] of the current OU

8. A user can only be an OU Member of one OU only, but can be Secretary, Deputy Head, and/or Head in any (multiple) OU at the same time

9. A user can act as all OU Roles in an OU in a workflow

About OU Member’s Role

The role of OU Member should follow as below:

1. The role of OU Member is for defining the starting point of request submission (OU and OU Level) in the overall OU hierarchy

2. OU Member is for submitting records only, and cannot be appointed reviewer in workflow

3. One user account can only be an OU Member of one OU only at a time

4. Submission made by an OU Member will always be submitted to the OU the Member belongs to for the first review by default

• If want to submit to another OU for approval, require additional settings in Workflow Edge e.g. submit to specific OU or specific OU Level

About OU Secretary, OU Deputy Head and OU Head’s Role

The role of OU Secretary, OU Deputy Head and OU Head should follow as below:

1. The three roles serve as the low, mid and high rank reviewers in an OU respectively

2. The three roles do not offer function or feature other than being reviewers in workflow

3. A user is not required to be a member of an OU in order to be assigned Secretary, Deputy Head, and/or Head of the OU

4. A user can be assigned Secretary, Deputy Head, and/or Head in any (multiple) OU at the same time

5. When assigned multiple reviewer roles, the user has to act as a reviewer in all the assigned roles in workflow

6. If an OU Role responsible for review is vacant, the request will be considered approved and escalated to the next OU Role following Next Stakeholders settings in Workflow Edge Property Settings

• More on vacant OU Roles handling in the approval flow will be discussed in the next chapter "Setting Up Stakeholder Mappings by OU in Workflow Flow"

Setting Up Stakeholder Mappings by OU in Workflow Flow

1. Converting the client's company hierarchy into a tree diagram

• Determine the OU Level of each OU

• Explore potential issues in OU setting, and look for solutions/workarounds

  • • How to configure an OU if it reports to two Upper OU in real life, while the system only allows one Upper OU?

2. Mapping real life users with DragOnce org chart OU Roles

• Study the rank and duties of a user, and determine the appropriate OU Role(s) for the user account

  • • Staff of the highest rank in a department/team e.g. manager, president etc. could be categorized into OU Head role

    • Staff of the 2nd highest rank in a department/team e.g. vice manager, vice president etc. could be categorized into OU Deputy Head role

    • Other lower rank staff with rights to review request submissions eg. secretaries, assistants etc. could be categorized into OU Secretary role

    • All staff in the department/team who will submit approval requests should be categorized into OU Member role

• Explore potential issues in OU Role mapping, and look for solutions/workarounds

  • • How to configure a user if he reports to more than one OU in real life, when the system only allows one user to be an OU Member of one OU at a time?

3. Establishing company org chart in the platform

• In Admin Panel, prepare respective Excel file and import to create

  • • User Accounts

    • User Groups (if necessary)

    • Organizational Unit

• In Batch Update OU Excel file, use "Org Units" sheet to create/update OU, and "OU Members" sheet to assign OU and OU Roles to user accounts

4. Setting up approval flow by OU Mapping

In Workflow Edge Property Settings, Next Stakeholder Mapping menu, select OU Mapping

• Select an option in Setup OU Reference Point menu to determine how to define which OU user(s) to be the next stakeholder(s) in workflow

• Use Previous OU Reference Point: check the last OU Role that reviewed the request, and follow Next Stakeholder settings and platform org chart to look for the appropriate upper OU Role(s) to be the next stakeholder(s)

  • • The submitter/requester must be an user account registered in the org chart to establish a starting point in company hierarchy for mapping

    • The request must be reviewed in a prior state under OU Mapping to establish an OU Reference Point for mapping

    • This option cannot be used in the Workflow Edge which submits the request to first review (no OU Reference Point established yet)

    • This option cannot be used in the Workflow Edge which submits the request to first review (no OU Reference Point established yet)

    • Always follow OU Role mappings in Next Stakeholders settings section underneath to define the next stakeholder(s)

• Creator: look for next stakeholder(s) in the OU the record creator belongs to

  • • It is not necessary for the record creator to be the submitter/requester selected in User Picker in a form of the request

    • The record creator must be an user account registered in org chart (stakeholder not registered in org chart cannot establish a starting point in company hierarchy for mapping)

    • The submitter/requester selected in User Picker in a form can be an user account not registered in org chart

• Action Taker: look for next stakeholder(s) in the OU the action taker belongs to

  • • It is not necessary for the action taker to be the submitter/requester selected in User Picker in a form of the request

    • The action taker must be an user account registered in org chart (stakeholder not registered in org chart cannot establish a starting point in company hierarchy for mapping)

    • The submitter/requester selected in User Picker in a form can be an user account not registered in org chart

    • If a stakeholder delegated the rights to review a request to another user, Action Taker will be the delegated user that performed review action

• User Picker in Form: define next stakeholder by the OU Role of the user account selected in a User Picker widget in the form

  • • Commonly used in the Workflow Edge which submits the request to first review, to establish starting OU by submitter/requester and define approval path in future actions

    • The referenced User Picker widget must not be empty when perform action

    • The selected user must be an OU Member registered in the org chart to establish a starting point in company hierarchy for mapping

    • If the User Picker widget allows multiple selection, the first account in the sorted selection list will be referenced

      • • It is always suggested the User Picker widget for OU Mapping should allow only one selection, and selection by User picker type only

• Specific: enforce review by a specific OU

  • • The selected OU can be any OU in the org chart

    • The selected OU will always be the next OU to review the request, no matter it is the same OU as the current OU, on a lower OU level, or not a designated upper OU of the submitter/requester

• If input a value in Minimum OU Level field, system will look for the next stakeholder(s) starting from the stated OU level

  • • If the OU or OU Role mapped by Next Stakeholders settings does not fulfil the Minimum OU level requirement, all OU Roles below the required OU level will be considered having approved the request, and the request will follow Next Stakeholders settings and be escalated to the next qualified OU Role

• If select Use Previous OU Reference Point in Setup OU Reference Point menu, after an OU Secretary, OU Deputy Head or OU Head user performed action in the previous state, system will follow Next Stakeholders settings to look for the next stakeholder(s) in the target OU and OU Role(s)

• Multiple OU Roles can be mapped as next stakeholders in a state

  • • If no one in the OU has reviewed the request, Secretary, Deputy Head and/or Head of the OU can be the next stakeholder(s)

    • If the request is reviewed by OU Secretary, the next stakeholder(s) in current OU can only be Deputy Head and/or Head

    • If the request is reviewed by OU Deputy Head, the next stakeholder(s) in current OU can only be Head

    • If the request is reviewed by OU Head, the next stakeholder(s) can only be Secretary, Deputy Head and/or Head in the next OU

• If next stakeholder(s) should be in current OU, mapping in each OU Role only allows selection of roles of higher ranks:

  • • If previous stakeholder is OU Secretary or OU Deputy Head, the next stakeholder can be from the same OU level or next OU

    • If previous stakeholder is OU Head, the request will always be escalated to the next OU

• System will first define next stakeholder(s) by Next Stakeholders settings, then compare the OU level of the defined stakeholder(s) with settings in Minimum OU Level

  • • If the mapped OU or OU Role does not fulfil the OU level requirement in Minimum OU Level, the request will be considered having approved and follows Next Stakeholders settings to escalate until finally reached a qualified OU Role

• If an OU Role responsible for review is vacant, the request will be considered approved and escalated to the next OU Role(s) following Next Stakeholders settings

• If there is no qualified Upper OU or Upper OU Role available for escalation, action cannot be completed

• If options other than Use Previous OU Reference is selected in Setup OU Reference Point, the action will disregard the OU or OU Role of previous stakeholder, and always refer to the mapping in No One Reviewed option in Next Stakeholders settings

• When there are other Workflow Edge actions using other stakeholder mappings taken between the two Workflow States using OU Mapping, the latter state will refer to the last previous states using OU Mapping to define OU Reference Point

• When press Undo button, OU Reference Point will be reverted to that in the Workflow State returned to

• When press Withdraw button, OU Reference Point will be reset

5. Setting up return action

• Create a Workflow Edge to connect a review state and the state to return to

• In Workflow Edge Property Settings, Next Stakeholder Mapping menu, select Use Previous Stakeholders

• In Choose Specific Previous State menu, select the appropriate stakeholder for the target state (the state to return to)

  • • If a request is being returned an earlier state and be submitted again, OU Reference Point will be overwritten by the latest Submit action

6. Stakeholders/reviewers along an approval path are not defined upon or before request submission 

Stakeholder(s) for every state is defined when performing Workflow Edge action, based on the settings in Workflow Edges and other variables e.g. OU Reference Point at that moment

Example of OU Mapping Approval Flow #1: Loop Flow

Below are guidelines to build above example of OU Mapping Loop Flow:

1. First reviewer to be defined by the OU of the submitter, as selected in Submitter User Picker in the form

• In Submit Workflow Edge, Workflow Edge Property Settings,

  • • In Next Stakeholders Mapping menu, select OU Mapping

    • In Setup OU Reference Point menu, select User Picker in Form

    • In Choose a User Widget menu, select Submitter

    • Configure Next Stakeholder mappings for each OU Role review status

• • • In above example of Submit Workflow Edge settings:

      • • When press Submit button, the request will be submitted to the OU the user in Submitter User Picker belongs to

        • As no user in the OU has reviewed the request in previous states, the first stakeholder will be the users in OU Role(s) selected in No One Reviewed mapping

        • If a request is being returned or withdrawn to Preparing state and submitted again, OU Reference Point will be overwritten by the latest Submit action

2. The Diverter is to determine when an approval flow should be completed

Demonstration

Below demonstrating a simple case on how to use ‘App Data Sharing’.

1. Create a new application, name it as ‘Lunch Menu’ (Source Application) and create a page called ‘Lunch Menu’. On this page, the user will type in all the dishes in the form.

2. After building the page, save and preview the page. Then add some choices in the ‘Lunch Menu’ form.

3. Create another new application, name it as ‘Lunch Ordering’ (Target Application), add a page called ‘Lunch Ordering’. In this form, the user will order the lunchbox and the choice is referring to the dishes which were added in the Source Application form. 

4. As expected, the dropdown list should contain the dishes name which are the records in the Source Application’s ‘Lunch Menu’ form. Therefore, App Data Sharing should be set in the source application.

5. Back to the App List, click on ‘More’ and select ‘App Data Sharing’ in the collapsed area.

6. Scroll down and find the Target Application’s name, click on the button beside ‘Data Share From’. Select the form(s) in the Source Application that is about to share with the Target Application and submit the changes.

7. Back to the target application’s ‘Lunch Ordering’ form. Open the widget property settings of the widget ‘Order Dish’.

8. In the Value section, select ‘Use Widget Values From Other Form’ as the Options Source Type.

9. Select the shared form as the ‘Data From Page’ and ‘Dish Name’ as ‘Widget’.

10. Save and preview the page ‘Lunch Ordering’. Click on the dropdown list ‘Order Dish’, the data shared from ‘Lunch Menu’ should display properly in the dropdown list.