Configuration Concepts

Only for Superuser and Configurators in the Organisation

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 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.


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 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.

Here is a Karnataka hierarchy of locations:

India (Country)

Karnataka (State)

Bangalore Rural (District)

Ramanagara (City/Town/Village)

Here is a Tamil Nadu hierarchy of locations:

India (Country)

Tamil Nadu (State)

↳ Madurai (District)

Karseri (City/Town/Village)


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.


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.


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.


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 are at the core of how DICEFlow deploys field process of your organisation. Some examples of the same:

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

And some explicit attributes:

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 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. 

Ok. Now, that I know the whole spiel, what next?

We have explained how to setup a Sample Survey in this page. You can use the explanation and define your own project


There is a one click button within the Structure page which does the grunt work and sets up a simple project for you. Please refer to image below