Let apps mark a pinned command menu item as the primary action

[admin-laicadev]

An app can pin a command menu item (isPinned: true). The item then shows as a button in the record page header. We use this for the main action on a record (for example "Send invitation" on a meeting). But app buttons always use the secondary style. Only three built-in actions can be primary.

In PinnedCommandMenuItemButtons.tsx the primary style is hardcoded:

isPrimaryAction={
  item.engineComponentKey === EngineComponentKey.CREATE_NEW_RECORD ||
  item.engineComponentKey === EngineComponentKey.COMPOSE_CAMPAIGN ||
  item.engineComponentKey === EngineComponentKey.SEND_MESSAGE_CAMPAIGN
}

CommandMenuItemManifest has no property for this.

Describe the solution you'd like

An optional property on the command menu item, for example:

defineCommandMenuItem({
  // ...
  isPinned: true,
  isPrimaryAction: true,
})

PinnedCommandMenuItemButtons would then use item.isPrimaryAction || <the current engine key check>.

Describe alternatives you've considered

• A conditionalPrimaryExpression, the same as conditionalPinnedExpression. Then an action can be primary only in some states (for example only while the invitation is not sent yet. Once it has been sent, the secondary buttons is fine).
• Our own button in a front component widget (not tried). The action is then not in the command menu, and it does not look like the other header buttons.

Additional context

• Twenty v2.41.0 (self-hosted), tag twenty/v2.41.0 = d1bb92d111f91529478da56aa677efbdba230c00
• twenty-sdk 2.41.0

[twenty-eng-sync[bot]]

Issue proposes that pinned command menu items should be allowed to render as the primary header action when provided by an app. Currently, PinnedCommandMenuItemButtons.tsx hardcodes primary styling based only on EngineComponentKey values (CREATE_NEW_RECORD, COMPOSE_CAMPAIGN, SEND_MESSAGE_CAMPAIGN), and CommandMenuItemManifest lacks a flag/expression to mark an item as primary. Severity: MEDIUM because this blocks app-defined UX consistency for record header actions but does not appear to break core flows; it’s an extensibility/design bug. Root-cause hypothesis (code not fetched due to path mismatch/limited budget): frontend record header rendering in packages/twenty-front/src/modules/record (component PinnedCommandMenuItemButtons.tsx) should honor a new optional manifest property like isPrimaryAction or conditionalPrimaryExpression; additionally extend CommandMenuItemManifest. Confidence: low. Missing report: reproduction steps (which app/engineComponentKey triggers the incorrect secondary styling), plus exact expected vs actual UI beyond the stated primary/secondary mismatch.

[martmull]

@Bonapara technically possible, wdyt on your side?