This solution details the general principles of the Myrmex data request workflow, for each role involved. If you need assistance on the workflow taking place inside a given data request, please refer to this solution instead : Workflow in Myrmex : Inside a request.

Data Request

The main purpose of Myrmex is to help organisations and their teams produce environmental and social reports based on actual activity data. In order to do so, Myrmex structures the data collection approach and lets organisations create Data requests, which are sent to data owners.

A standard data request in Myrmex is described by :

  • Parties (organisations) involved (mandatory) : see below section on Roles.
  • A report template (mandatory) : the actual report to be produced when the data request has been fulfilled. This template dictates the raw data set which will need to be encoded in order to compute Indicators to be formatted in the output report.
  • A requester (optional) : the user who will manage the request. This field is mainly used by large organisations which have a need to manage multiple parallel data collection campaigns led by different individuals.
  • A period (mandatory) : the reference year against which the data is collected. Myrmex currently only accepts regular calendar years to be defined for the request period.
  • A verifying party or an auditing party (optional) : see below section on Roles.
  • A due date (mandatory) : this is the date by which the requester needs the data set. It is mainly used to prioritise work in users' workbaskets.
  • A comment and/or and attachment (optional) : these additional fields let the requesting organisation give important information about the purpose and context of the campaign's objectives as well as what is requested. 
  • Reminders (optional) : the requesting organisation may add automatic reminders to the request, to remind other parties involved if they have no accepted or completed the request a customisable number of days before the expected date.

Roles & Associated screens

The Myrmex data requesting workflow involves 2 roles :

  • The requesting organisation a.k.a the requester : the organisation who wants to produce a defined report or consolidated report within Myrmex, and who creates the data request.
  • The data providing organisation a.k.a the data provider : the organisation who responds to questions initiated by the request.

When both of the above roles are borne by separate organisations, the process is considered an external data request.

When both of the above roles are borne by the same organisation, the process is considered an internal data request.

Additionally, the requester can (but does not have to) define a proof-reading or certifying third party to work on the requested data :

  • The verifying organisation, which can check the validity of data elements for internal data quality purposes. This organisation can be the same as the requester's (internal verification), or can be performed by an external party (external verification)
  • The auditing organisation, which can only be performed by an external duly authorised organisation in Myrmex, and which attests publicly on the validity of provided data.

NB : Both modes (verification and audit), are currently exclusive in Myrmex.

The requester initiates a data request in the Requests screen.

The data provider manages his responses in the Workbasket screen.

The verifying or auditing organisation, if any, manages the data verification process in the Workbasket screen as well.


Verification's main focus is internal : it is a way for the data requesting organisation to increase the request's data quality by asking a dedicated actor to check answers encoded by the data providing organisation. 

Verification results and conclusions are only visible to the requesting organisation and to the data providing organisation. No other organisation in Myrmex may see the verification results (as opposed to audit, see below).

NB : The verifying user may belong to any organisation, including the requesting organisation.


Verification's main focus is external : it is a way for the data requesting organisation to require an official and certified review of any data encoded by the data providing organisation. 

Audit results and conclusions are durably linked to the actual data elements, and become visible to any organisation which sends an (accepted of course) data request to the data providing organisation in the future. It is therefore a way for the data provider to communicate on the high level of reliability of the encoded data set.

NB : The auditing user has to belong to a certified organisation, which cannot be the same as any of the other two parties (neither the requesting organisation, nor the data providing organisation).

Request Workflow & Statuses

At any time the request status tracks the request's progress and rules who can take action to move the process forward.

The request status is visible to all parties and is used to sort the Workbasket and Requests screens through tabs.

The diagram below shows the various statuses, paths allowed, and the corresponding actions which can be taken by each party to move from one status to the next :

The "normal" path a (verified) request should take is the following :

Pending > In Progress (> Ready for validation) > Finished

Only one status is final in the entire request workflow : the cancelled status. If any party cancels the request, the request is irreversibly sent to the Cancelled tab. Responses already given are still kept by the system though, and any new request in the future which requires them would be automatically populated accordingly.

Depending on the role your organisation has in a request, actions you can take depend on the request status and are listed below :

Request History

Similar to the way answers are tracked with a dedicated audit trail, Myrmex also logs any changes made to the request. You can view the request history by clicking on the "Request history" button :