G2PRegisterUITab
g2p_register_ui_tabs - UI Configuration (Tabs) for Registers & Program Registers
The g2p_register_tabs table stores tab definitions for registers within the OpenG2P Registry platform.
This configuration is applicable only to datasets classified as:
REGISTER
PROGRAM_REGISTER
The Registry Staff UI uses this metadata to dynamically render the tabbed interface when viewing or managing records within a register.
In addition to defining UI tabs, this table is also used to configure Intake Forms, which serve as input channels for creating new records in registers.
A register or program register may have multiple intake forms, each designed for different operational channels such as:
Staff Portal
Agent Portal
Beneficiary Portal
Attributes
tab_id
Primary key of the table. Uniquely identifies a tab definition across the platform.
register_id
Identifier of the register to which the tab definition belongs.
tab_label
The label displayed for the tab in the UI. The Staff UI automatically translates this label based on the user's language preference.
tab_order
Determines the order in which the tab appears for the register. Tabs with lower values appear earlier in the UI.
Intake Form Configuration
The following attributes apply when the tab is used as an Intake Form.
used_for_new_intake_form
Indicates whether the tab represents an intake form used to create new records in a REGISTER or PROGRAM_REGISTER.
intake_form_name
Name of the intake form. When multiple intake forms exist for a register, this name helps users distinguish between them when initiating a new intake process.
intake_form_description
A short description explaining the purpose of the intake form.
no_of_verifications_required
Specifies the number of verification steps required before the intake form submission can be approved.
intake_form_auto_approve
Indicates whether submissions from this intake form are automatically approved or require manual verification and approval before a change request is created.
Lifecycle Configuration
is_active
Indicates whether the tab or intake form is currently active. This allows administrators to retire forms that are no longer in use without deleting their configuration.
UI Behavior
The Registry Staff UI uses this metadata to dynamically:
Render tabbed views for registers
Present intake forms for record creation
Determine form workflows and verification requirements
Control tab ordering and visibility
This metadata-driven approach allows implementation teams to configure UI workflows without modifying application code.
Reference Implementation
Reference implementation of this table for a Farmer Registry can be found in the Farmer Extension repository - here.
Last updated
Was this helpful?