Urgent: Need related list to show different columns per record type + limit "New" button

[supriya1kum]

I have the OOTB Demand application. On the Demand form, once a demand is submitted, there's a list-type field called Demand Assessment with three choices:

• Infrastructure Assessment
• AI Assessment
• BIA Assessment

Users can select one or more of these. When the demand moves into the Screening state, a Demand Task record is auto-generated for each selected choice, with the task's Short Description set to match the choice (e.g. "Infrastructure capacity assessment," "AI Use case capacity assessment").

I've built a custom table, Demand Assessments, extended from Task, and added it as a related list on the Demand Task form so users can log the actual assessment details. This custom table has different sections of fields depending on the assessment type — e.g. for Infrastructure it has Infra Area, Subcategories, Estimated Cost, Estimated Quantity, Business Criticality, RTO, RPO, HA/DR fields; AI and BIA assessments have their own separate sets of fields.

Problem 1: Related list always shows the Infrastructure columns

No matter which Demand Task I open — whether it's the Infra one, the AI one, or the BIA one — the Demand Assessments related list on the Demand Task form always displays the same set of columns (Infra Area, Subcategories, Estimated Quantity, Estimated Cost (AED), Cost Included in Initial Demand Scope).

What I need instead: when the Demand Task is for AI Assessment, the related list should show the AI-specific columns; when it's for BIA, it should show BIA-specific columns; and only for the Infra Assessment task should it show the Infra columns as it does now.

I've attached screenshots showing:

• An Infra-type Demand Task (DMNTSK0001147) with the related list showing infra columns — expected.
• An AI-type Demand Task (DMNTSK0001150) — but the related list is still showing the same infra columns instead of AI-relevant ones.

Problem 2: Need to cap the number of records creatable in the related list

On the Demand Assessment form, there's an Infra Area field and a dependent choice field Subcategories — the options available in Subcategories change based on what's selected in Infra Area (predefined mapping).

What I need: the maximum number of Demand Assessment child records a user can create under a given Demand Task should equal the number of Subcategory options available for the Infra Area they picked. Once the user has created that many records, the New button on the related list should no longer be available — for that Demand Task.

The same rule needs to apply independently for AI Assessment and BIA Assessment tasks, each with their own logic for what determines the max count.

What I'm looking for

• Any existing approach / best practice for showing different related-list columns based on the type of parent record (Demand Task assessment type).
• Any reliable way to dynamically cap and hide the "New" button on a related list based on a count comparison against a dependent choice list's available options — ideally something that also works consistently between classic UI and Workspace, since we use both.

[Vikram Reddy · Accepted solution]

Hi @supriya1kum,

B​oth problems trace back to the same root cause: everything is riding on one auto-generated relationship pointed at one table, and a related list's columns belong to that relationship's List Layout, not to the parent record's type, so a single "Demand Assessments" related list will never show different columns per Demand Task just because the short description changes (that is exactly why DMNTSK0001147 and DMNTSK0001150 render the same Infra Area, Subcategories, Estimated Quantity, Estimated Cost (AED), Cost Included in Initial Demand Scope set).

Fix the columns with Defined Related Lists instead of the one implicit relationship: go to System Definition > Relationships, create three relationship records (Infra, AI, BIA), each querying Demand Assessments filtered on your assessment-type field, add all three to the Demand Task related list section, then use a UI Policy with a Related List Action to toggle Visible per relationship based on the task's type. That last part needs zero scripting, and each relationship carries its own List Layout so the columns stay independent per type.

For the New button cap, a few things to check before you pick an approach:

• the List Control "Omit new condition" script (right-click a column header > Configure > List Control) works in classic but is unreliable on Workspace-rendered related lists
• an ACL create-operation script on Demand Assessments that GlideAggregate-counts existing children against your computed max is enforced everywhere: classic, Workspace, and API, since it's a security check, not a list widget
• centralize the max-count logic in a Script Include so the ACL and both assessment types call the same source of truth

Thank you,
Vikram Karety
Octigo Solutions INC