Summary Enable Self‑Service Action forms to collect arrays of structured objects (add/remove rows) with validations and relationships, instead of forcing users into free‑form JSON/YAML. Context In our organization, we do not allow manual entity creation in the Port UI. Entities must be synced from systems of record. Therefore, when a user needs a “new entity” or a complex change, they must use a Self‑Service Action that triggers automation (workflow/API) to create/update data in the system of record, and then the catalog syncs back. This works well for simple blueprints. It becomes difficult for complex blueprints that require entering a list of related objects (or “child” objects), especially when the list is not a Blueprint entity selector. Problem Today, for self-service action forms, if the list items correspond to existing Blueprint entities, we can use a Blueprint field with "many" and multi-selection existing entities (very useful). If the list items are not tied to a Blueprint or represents entities of a Blueprint that are to be created in the system of record (via the self-service action form), the only real option is a JSON/Yaml free-from field. We loose the structure (which keys are needed?), the build-in validations (types, enums, required, etc), the consistent UX (error-prone and feels out of place compare to other form input). Pain point examples Creating a complex entity that includes an array like "owners[]", "endpoints[]", "contacts[]", etc. Each item has multiple fields (name, type, environment, references, etc). Proposed Solution Introduce a first-class form field type like "object_list" or "List of objects". Users can add item / remove item Each item is an object with a predefined schema or structure Each field in the object uses normal form controls and inputs (text, number, boolean, entity picker, required, default, etc.) It could possibly work in two distinct modes where both seems valuable: Schema-backed list (not from a Blueprint) Define the object structure inline in the action form or reference a reusable schema) Output is an array of objects to the action run payload Blueprint-backed list (powerful) Define each list item as "an entity-like object" tied to a Blueprint (with its schema (properties, validations and such)) Not necessarily creating entities in Port UI, but ensure consistent field definitions, reuse of property constraints and ability to reference relationships/pickers UX / UI Field appears as a table-like list or cards Each item shows a summary line, and edit button or inline editing Actions: Add Item Duplicate Item Remove Item Reorder items (drag and move) (could be useful) Validation per field, per-item, shows which row has errors, could limit the number of items in the list Example usage If I want to use a self-service action form to create a new service, in the form, the user could be ask to provide "endpoint[]" which is a complex object containing, as an example: name (string, required) url (string, required, url format) environment (enum) owner_team (entity picker from the _team Blueprint) is_public (boolean with a default) Today: The user would be force to fill in JSON or Yaml or, as a pre-condition, manually create the entities needed (if RBAC allows) Proposed: User adds 1..n endpoints via repeatable structured form rows. Additional Notes This would dramatically improve the self-service UX for complex onboarding or creating flows. This also enables broader adoption of Port actions being the primary creation path to respect system of record. This also reduces the failures or risks of malformed Yaml/JSON. A big plus is also to make the self-service actions more approachable and usable for less technical users (directors, managers, etc).
