Configuration Concepts

Here, we will describe how you can setup and use the DICEFlow application. Before that, you need to understand some of the key concepts explained in sections below.

Superuser Account

Email ID which was used to register your organisation will be the login to your Superuser account on DICEFlow application. This is the account under which ALL your organisation data is stored, managed, analysed and worked on.

Project

Project is the highest level entity wherein your organisation's data is stored. You can create as many projects as you like within your account. Each project's data is separate from other project's data within your registered account. Superuser alone has access to every project's data but individual user's can be given roles in each project. More on this later.

Hierarchy

Each Project has a hierarchy which needs to be defined. Hierarchy is a project structure in terms of organisation levels and roles. For example, Project1 has a hierarchy as follows:

Country with Roles: Country Director, Donor

↳ State with Roles: State Program Manager, Partner Manager

↳ District with Role: District Manager

↳ City/Town/Village with Role: Field Worker

Locations

Locations are the actual value we add per Hierarchy level we have defined. In the above hierarchy mentioned, actual locations which we will add maybe as follows. Notes in ( ) only depict the level.

India (Country)

↳ Karnataka (State)

↳ Bangalore Rural (District)

↳ Ramanagara (City/Town/Village)

Locations need to be added in the structure defined for the project. They drive how DICEFlow manages access to the data.  You can have multiple hierarchy of locations defined based on where your projects are based.

Permissions

Access to pages and entities (Users, Members, Groups, Workflows) is given at each Role level. DICEFlow has granular permissions in the form of NONE, READ and WRITE levels. If a Role is given READ access to a page, say Structure. User of that Role can view the Structure page but will have not add/edit operations enabled on that page. Similarly, if a Role is given WRITE access to a Workflow Type, they can view/add/execute the workflows of that type.

Users

You have defined a Hierarchy levels and the Roles at each of these levels. Users are accounts who have login access to DICEFlow application and can use the same post successful login. These maybe your program/project people on the field or at higher levels, who are add, updating and monitoring work and resulting data within the application.

☞ Users are assigned locations so the data they see is dependent on locations assigned to them in each project. How is this data shown to user? Explained in Members section below.

Members

These are individuals to whom your program reaches out with various services. They don't have a login on the system but are tracked/serviced by field people (who are Users, mentioned above). These can also be other data like Schools, Hospitals, Offices etc. Basically, any data which has attributes and history. DICEFlow requires you to have at least one Member Type in case you want to be able to track them. Members are added to the bottom most level in the hierarchy. Lets take the example of Karnataka hierarchy

India (Country)

↳ Karnataka (State)

↳ Bangalore Rural (District)

↳ Ramanagara (City/Town/Village) ☜ Members are added here

☞ When Members are added to the lowest location, it becomes easy to analyse data at each level of the hierarchy. So, a member added to Ramanagara also belongs to Bangalore Rural District, Karnataka State and India Country. So, aggregating data per level is inferred from the hierarchy.

☞ User who is assigned to Bangalore Rural (District) location will see data of all Members under all Cities/Towns/Villages defined under that district. In the above example, only 1 City/Town/Village has been defined but you are free to define more and assign multiple such locations to users.

Groups

We can bunch multiple Members into a Group of a pre-defined type.  DICEFlow requires you to have at least one Group Type in case you want to be able to track Members in such groups.

Workflows

Workflows are at the core of how DICEFlow deploys field process of your organisation. Some examples of the same:

• Member Enrolment

• Member Visit

• Student Grades

Workflows in DICEFlow need to have some implicit attributes defined namely:

• Statuses - List of statuses workflow will go through in their lifetime

• Due Date - Date by which the next step in the workflow needs to be completed

And some explicit attributes:

• Customfields - Data collected throughout their lifetime

Workflows are of 2 types:

Affiliated - These workflows are connected to one or all defined Members OR Groups. That way, you have access to all the Member or Group data during the execution of the Workflow. For example, you have an affiliated (to Member Type) workflow called Doctor Visit which creates an SOP for visit to a Doctor in your project. During the execution of the workflow, you have access to Member's Date of Birth, Gender and other Member specific attributes which you will have collected earlier when you added the Member to the application.

Unaffiliated - This type of workflow is used when you have a process for entities other than Member or Group. For example, you are doing a survey among your users about services you want to add to your project.

Flowcharts

Flowcharts are the low code builder environment by which you can define the logic of Workflows, Dashboard Visualisations, Reports and special fields called Computed Fields. If you have heard of Scratch programming, you will understand what we are bringing to the table. DICEFlow extends that concept in an enterprise mode with elements of task management, business process deployment and data visualisation/reporting built in.

Custom Fields

You will see this term sprinkled across the application. Most entities (Roles, Member, Group, Workflow) in the DICEFlow application have attributes associated with them which can be updated either directly or via Workflows. These are data you stored which are related to that entity. For example. Members' Age, Group's Address, Workflow's Date of Last Update, User's Last sync time etc.