Decision: Autosave or manual save? One phase or two?

• Problem to solve
  • How/when should these fields and objects be saved?
• Reference
• Options
  • 1️⃣ Auto-save the category, instantly save the attributes
  • 2️⃣ Manual save, one phase: Category/attributes are all saved together when one main Save changes button is pressed
  • 3️⃣ Manual save, two phase: Category is saved with a Save category button outside the drawer, attribute changes are saved with an Save attribute button inside the drawer
  • 4️⃣ Something else?

Problem to solve

How/when should these fields and objects be saved?

We have a form that looks something like this in its most basic form:

This much we know:

• Categories are listed on the left and clicking on a category opens it in the form for editing
• Clicking Create category opens a blank form
• Each category has some metadata (name, description, selection type)
• Each category contains attributes which will be assigned to projects and they're shown in the table
• Clicking on an attribute's ⋮ opens the attribute in the drawer/form for editing
• Clicking Create attribute opens the drawer with a blank form

... but should we autosave as the form is filled out or should there be one or more save buttons somewhere? If there are buttons in the drawer, do they apply the changes immediately or do they stage them to be saved once another save button is clicked?

Reference

• design issue: Design: Security Attributes (#547963)
• epic: Security Attributes/Context Filtering (&18010)
• design system documentation on saving and feedback: https://design.gitlab.com/patterns/saving-and-feedback

Options

1️⃣ Auto-save the category, instantly save the attributes

Prototype:
Screen_Recording_2025-07-18_at_19.47.43

This was how it was intended to work in an earlier iteration of the designs:

Example of creating a new category. The category should auto-save after any information (name, description, labels) is added.
#547963[Security_configuration_-_group-level_-_security_labels_-_category_details_-_New_category.png] (comment 2562083364)

Consistency with related features:

• Similar to editing the Requirements section of a framework in Secure => Compliance center => Frameworks

Advantages:

• Lower complexity to implement
• Takes fewer clicks to complete tasks

Concerns:

• Don't most GitLab forms have save buttons?
  • Mitigation: Confirm that changes were saved with a toast.
  • Mitigation: Consult the Design System guidance for autosave.
  • Counterargument: Don't most GitLab drawers save instantaneously?
• What happens if the user tries to navigate away from a category without filling in all the required fields?
  • Mitigation: Which fields are required? Maybe we could:
    • Require only name
    • Set "Selection type" to "Single selection" by default
    • Confirm the change to "Multiple selection" with an "Are you sure?" because it would be permanent
  • Related concern: Will users create a bunch of junk categories because they're autosaved?

2️⃣ Manual save, one phase: Category/attributes are all saved together when one main Save changes button is pressed

Prototype 1	Prototype 2
Screen_Recording_2025-07-18_at_21.34.56	Screen_Recording_2025-08-05_at_18.59.28

Consistency with related features:

• Similar to Secure => Policies
• Similar to DAST profile library (Secure => Security configuration => Dynamic Application Security Testing (DAST) => Manage profiles
• Similar to Secure => Compliance center => Frameworks

Advantages:

• A category without any attributes is useless so we guide the user to create both at once
• Changes are more likely to be intentional because they must be manually saved

Concerns:

• Higher complexity to implement:
  • frontend must store a draft of changes to save.
  • backend must handle one large request that contains many operations at once.
  • Larger requests are more likely to time out, more likely to conflict with other requests, and harder to troubleshoot.
  • The larger the request, the more frustrating it would be for the user if it fails and they lose their changes.
• It might be unclear to the user that they have to save changes.
  • Mitigation: Add an unsaved changes indicator either next to the save button or mark the form fields.
  • Mitigation: Store the draft changes in localStorage (like when you're writing a comment on an issue/MR) so they don't get lost
  • Mitigation: Add an Are you sure? modal triggered by navigating away with unsaved changes to confirm they want to discard them.
    • We can definitely do this if they click on another category, but to do this if they navigate away completely to another page requires a separate browser-level dialogue and that might be too disruptive.

3️⃣ Manual save, two phase: Category is saved with a Save category button outside the drawer, attribute changes are saved with an Save attribute button inside the drawer

Prototype (trying out a different save button placement):
Screen_Recording_2025-07-09_at_10.07.50

Consistency with related features:

• Similar to Settings => CI/CD => Variables
• Similar to Settings => Merge requests => Approval rules

Advantages:

• Lower complexity to implement
• Changes are more likely to be intentional because they must be manually saved

Concerns:

• We end up with a lot of buttons competing for attention and space, which could be confusing to use because it's unclear which buttons save which sections.
  • Mitigation: Move the category-save button up above the attribute table?

4️⃣ Something else?