Does n8n provide a built-in layout for a primary node that incorporates multiple action nodes?

How can I design an n8n node so a main module governs distinct functions without generating separate core nodes? Below is a revised example:

{
  "modules": {
    "core": [
      "src/nodes/core/login.node.js",
      "src/nodes/core/upload.node.js"
    ]
  }
}
export class ServiceAction {
  config = {
    displayName: 'Service',
    name: 'service',
    icon: 'file:service.svg',
    group: ['operations'],
    version: 1,
    defaults: { name: 'Service', color: '#D455D9' },
    inputs: ['main'],
    outputs: ['main'],
    properties: [
      {
        displayName: 'Function',
        name: 'function',
        type: 'options',
        options: [
          { displayName: 'Login', name: 'login', value: 'login', description: 'User login' },
          { displayName: 'Upload', name: 'upload', value: 'upload', description: 'File upload' }
        ],
        default: 'login',
        description: 'Select the operation'
      }
    ]
  };
}

n8n does not offer a specific built-in layout that automatically groups multiple action nodes under one primary module. In my experience, achieving a similar structure requires you to manage the node properties to determine the operational mode. This means you’ll need to manually define the conditional logic in your node definition to differentiate between actions such as login and upload. While the approach you’ve taken in your example is valid, it may call for extra handling to ensure a clear and manageable interface for the user.

n8n doesnt have a native layout for that. you have to manually handle diffirent actions by coding conditional logic. its a bit clunky, but your custom approach seems to be the way most users end up doing it.

n8n does not have a built-in layout that neatly groups multiple action nodes under one primary module without additional coding. Indeed, over time I have found that while using a single node with different action parameters reduces clutter in the workflow, it also calls for more careful management of property logic. In my personal experience, creating a node with a switch-like mechanism to decide which function to execute not only consolidates multiple tasks into one node but also demands clear internal checks to keep the code maintainable and transparent. This trade-off is manageable with good code organization.