G2PRegisterSection
g2p_register_sections
The g2p_register_sections table defines sections within a tab of a register. Each tab can contain one or more sections, where each section represents a logical grouping of related attributes.
Examples of sections include:
Personal Profile
Educational Qualifications
Employment Details
Income Details
Sections are the primary unit of modification within a register. During edit operations, only one section can be modified at a time.
Any modification to a section creates a Change Request (CR). The change request must undergo verification and approval before the changes are written to the corresponding REGISTER or PROGRAM_REGISTER dataset.
Attributes
section_id
Primary key of the table. Uniquely identifies a section across the platform.
register_id
Identifier of the register to which this section belongs (for display in the UI).
tab_id
Identifier of the tab under which this section appears.
section_register_id
Specifies the underlying dataset that the section operates on.
Section Data Source
The section_register_id determines the dataset that provides the data for the section.
Example scenario:
A Household Register contains a tab showing Individuals belonging to the household.
Within that tab, there may be a section displaying the list of individuals.
In this case:
register_id→ Household Register (used for display context)section_register_id→ Individual Register (actual data source)
If the data shown in the section belongs to the same register in which the section appears, then:
Cross-Register Editing Rules
If section_register_id refers to another REGISTER (not a TABLE), the section becomes display-only.
The platform does not allow cross-register modifications.
For example:
A Household Register may display Individuals belonging to the household.
However, edits to Individual records must be performed within the Individuals Register itself.
The platform does allow modifications to TABLE datasets from within the parent register.
Section Lifecycle Attributes
is_primary_section
Indicates that the section is the primary and mandatory section required for creating a record in the register. A record cannot be created without this section.
section_order
Defines the order in which sections appear within a tab.
section_mnemonic
Unique name used to identify the section within the platform.
section_description
Describes the purpose and contents of the section.
Intake Form Behavior
When an intake form contains multiple sections:
Submitting the intake form creates Change Requests for each section.
The primary section is processed first.
Once the intake submission is approved, the associated change requests are automatically approved.
This process ensures that the record is created only after the mandatory section has been validated.
Document Requirement Configuration
documents_required
Boolean flag indicating whether documentary evidence must be submitted when creating or modifying records in this section.
When this flag is enabled, the UI allows users to upload supporting documents as proof for the claims made in the section.
Verification Configuration
no_of_verifications_required
Specifies the number of independent verifications required before a change request for this section can be approved.
This allows the platform to support multi-level verification workflows for sensitive information.
UI Configuration
is_list
Indicates whether the section represents multiple records for a given register record.
Example:
An Individual may have multiple Public Utility Subscriptions. In such cases, the section listing the subscriptions would have:
section_ui_schema
section_ui_schemaThis attribute contains a JSON schema that defines how the UI should render the section.
The schema describes how the section should behave in:
View mode
Edit mode
The Registry UI dynamically renders the section interface using React components based on this JSON schema.
This metadata-driven approach allows UI changes without modifying frontend code.
Change Request Auto-Approval Configuration
The following attributes control whether change requests generated from different operational channels are automatically approved.
cr_auto_approve_for_bene_portal
Auto-approve change requests originating from the Beneficiary Portal.
cr_auto_approve_for_agent_portal
Auto-approve change requests originating from the Agent Portal.
cr_auto_approve_for_staff_portal
Auto-approve change requests originating from the Staff Portal.
cr_auto_approve_for_partner
Auto-approve change requests originating from Partner systems or integrations.
If the value is FALSE, the generated change request must be manually verified and approved before the changes are applied to the register.
Reference Implementation
Database scripts for g2p_register_sections for a Reference Farmer Registry are available here.
Last updated
Was this helpful?