# Account profile in form section statuses

Suggested schema (to request from H8):

{
    "success": true,
    "data": {
        "accountprofiles": {
            "UserId1": { // Need to expose userId to front end in application details
                "CV": {
                    "applicantStatus":"InProgress",
                    "researchOfficeStatus":"NotChecked",
                    "researchOfficeComments":"RICH TEXT VALUE"
                },
                "PersonalDetails": {
                    "applicantStatus":"NotStarted",
                    "researchOfficeStatus":"NotChecked",
                    "researchOfficeComments":"RICH TEXT VALUE"
                },
                "DiversityMonitoring": {
                    "applicantStatus":"NotStarted",
                    "researchOfficeStatus":"NotApplicable", // new status because ROs won't check DMI data
                    "researchOfficeComments":""
                }
            },
            "UserId2": {
                ...
            },
        },
        "formsections": {
            "F000123": {
                "applicantStatus":"InProgress",
                "researchOfficeStatus":"NotChecked",
                "researchOfficeComments":"RICH TEXT VALUE"
            },
            "F000456": {
                "applicantStatus":"NotStarted",
                "researchOfficeStatus":"NotChecked",
                "researchOfficeComments":"RICH TEXT VALUE"
            }
        }
    },
    "metadata": {}
}

Questions:
* Should we use email (because we already return that to the front end) rather than userId as the key for each applicant's data?
* No - we'll switch to using UserIds and pass those with application data
* How much of a pain will it be for the schema to change (adding in "formsections" layer) rather than leaving those at the top level?
* We can prepare for this in the middleware before H8 release
* Do we need a new status for the DMI information, assuming the RO won't see that, to show that it won't be checked?
* Yes - NotApplicable