Handling Multiple Submit Buttons in ASP.NET MVC

You will learn that a submitted form includes the name and value of the submit button that was clicked. By giving each button a shared name and a distinct value, a controller action can decide whether to send, cancel, save, delete, or perform another operation.

HTML forms submit name/value pairs. Text inputs, checkboxes, hidden inputs, and the clicked submit button can all contribute values to the HTTP POST request.

A submit button without a name is not useful for identifying the user's choice on the server. Give the buttons the same name, such as command, and different values:

<input type="submit" name="command" value="Send" />
<input type="submit" name="command" value="Cancel" />

When the user clicks Send, the request contains command=Send. When they click Cancel, it contains command=Cancel.

In ASP.NET MVC, model binding maps that posted value to an action parameter with the same name. The action can then branch to the appropriate behavior.

This matters because one screen often offers several intentional outcomes: save a draft, submit a record, cancel editing, delete an item, or preview content. The server must not guess which outcome was intended.

Think of a form as an envelope containing labelled cards. Each form field puts one labelled card into the envelope, such as email=ada@example.com.

Each submit button is also a labelled card, but only the button the user presses is placed in the envelope. If the user presses Send, the envelope includes command=Send; if they press Cancel, it includes command=Cancel.

Your controller opens the envelope and reads the command card before deciding what to do.

Use a shared name and distinct value attributes for related submit buttons.

<% using (Html.BeginForm("MyAction", "MyController", FormMethod.Post))
   { %>
    <input type="text" name="message" />

    <input type="submit" name="command" value="Send" />
    <input type="submit" name="command" value="Cancel" />
<% } %>

Receive the selected value in the controller:

[HttpPost]
public ActionResult MyAction(string message, string command)
{
    if (command == "Cancel")
    {
        return RedirectToAction("Index");
    }

    if (command == "Send")
    {
        // Save or send the message.
        return RedirectToAction("Sent");
    }

    return new HttpStatusCodeResult(400, "Unknown command.");
}

The parameter name, command, matches the buttons' name="command". MVC binds the button's posted value to that parameter.

Consider this form:

<% using (Html.BeginForm("MyAction", "Messages", FormMethod.Post))
   { %>
    <input type="text" name="message" value="Hello" />
    <input type="submit" name="command" value="Send" />
    <input type="submit" name="command" value="Cancel" />
<% } %>

And this action:

[HttpPost]
public ActionResult MyAction(string message, string command)
{
    if (command == "Cancel")
    {
        return Content("Nothing was sent.");
    }

    return Content("Sent: " + message);
}

If the user clicks Send:

1. The browser collects the form fields.
2. It posts message=Hello.
3. Because Send was clicked, it also posts command=Send.
4. MVC binds message to "Hello" and command to "Send".
5. The Cancel condition is false, so the action returns Sent: Hello.

If the user clicks Cancel, the request contains command=Cancel. The action returns immediately without sending the message.

• Edit forms: provide Save, Save Draft, and Cancel choices.
• Administrative pages: provide Approve and Reject actions for an application or review.
• Shopping workflows: provide Place Order and Return to Cart buttons.
• Content systems: let authors Preview, Publish, or Delete an article.
• Support tools: let an agent Reply, Close Ticket, or Escalate a case.

For actions that are destructive, such as delete or publish, verify authorization and validate the current record state on the server. A button value is user input and must not be trusted by itself.

A common MVC pattern is to post a view model plus a command value, then use guard clauses for commands that should not run full validation.

[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Edit(OrderEditViewModel model, string command)
{
    if (command == "Cancel")
    {
        return RedirectToAction("Details", new { id = model.Id });
    }

    if (command != "Save" && command != "SaveDraft")
    {
        return new HttpStatusCodeResult(400, "Unknown command.");
    }

    if (!ModelState.IsValid)
    {
        return View(model);
    }

    if (command == "SaveDraft")
    {
        // Save an incomplete order.
        return RedirectToAction("Drafts");
    }

    // Save the completed order.
    return RedirectToAction("Details", new { id = model.Id });
}

Useful project practices include:

• Use a descriptive name such as command, operation, or intent.
• Use constants or an enum-like set of known command strings to avoid scattered typos.
• Handle Cancel before validation when it should simply navigate away.
• Return the same view with validation errors for save-related commands.
• Add [ValidateAntiForgeryToken] to state-changing POST actions and render an anti-forgery token in the form.
• Check permissions and record ownership on the server for every command.

Omitting the name attribute

This does not give the controller a reliable command value:

<input type="submit" value="Send" />
<input type="submit" value="Cancel" />

Fix it by adding a shared name:

<input type="submit" name="command" value="Send" />
<input type="submit" name="command" value="Cancel" />

Giving both buttons the same value

<input type="submit" name="command" value="Submit" />
<input type="submit" name="command" value="Submit" />

The server cannot tell them apart. Use unique values.

Matching the action parameter to value instead of name

This is incorrect because MVC matches input names to parameter names:

public ActionResult MyAction(string Send)

Use the input name instead:

public ActionResult MyAction(string command)

Trusting an unrecognized command

A client can send any posted value, not only values shown by your page. Reject unexpected values and perform authorization checks.

Validating before handling Cancel

If cancel should leave the page without saving, checking ModelState.IsValid first can block it because required fields may be empty. Handle the cancel command first.

Putting delete and save in one ambiguous branch

A delete command should have a clearly separate branch, authorization checks, and usually a confirmation step. Do not accidentally treat every non-cancel command as save.

A Cancel option is frequently better as a link when it does not need to submit any data:

<%= Html.ActionLink("Cancel", "Index") %>

Use a submit button for cancel only when the server must receive the cancellation request or record a workflow event.

<!-- Same name, distinct values -->
<input type="submit" name="command" value="Save" />
<input type="submit" name="command" value="Cancel" />

[HttpPost]
public ActionResult Edit(MyViewModel model, string command)
{
    if (command == "Cancel")
    {
        return RedirectToAction("Index");
    }

    if (command == "Save" && ModelState.IsValid)
    {
        // Save model
    }

    return View(model);
}

• MVC binds an input's name to an action parameter.
• The clicked submit button provides its value.
• Only the clicked submit button is normally included in a browser form submission.
• Treat command as untrusted input; allow only known values.
• Handle navigation-only commands such as Cancel before model validation when appropriate.
• Prefer a normal link for Cancel when no POST is needed.

How does ASP.NET MVC know which submit button was clicked?

The browser posts the name=value pair for the submit button that initiated the form submission. MVC model binding maps that value to an action parameter with the same name.

Do multiple submit buttons need the same name?

Use the same name when they represent alternative commands for one action, such as command=Save and command=Cancel. This lets one parameter hold the selected command.

Can I use different names for each button?

Yes, but it is usually less convenient. You would need to test which parameter is present. A shared command name is clearer for mutually exclusive actions.

Why is my command parameter null?

Check that the clicked submit button has a name attribute and that its name matches the action parameter exactly. Also ensure the button is inside the submitted form and is not disabled.

Should Cancel be a submit button or a link?

Use a link if cancel only returns the user to another page. Use a submit button when the server must receive and process the cancellation.

Can a user modify the command value in the request?

Yes. Any client-side value can be changed. Validate the command against allowed values and enforce authorization and business rules on the server.

Can I use separate actions instead of one action with a command?

Yes. Separate actions can be a good design when operations have substantially different validation, permissions, or side effects.

• ASP.NET MVC model binding — Maps posted form names and values to action parameters and view-model properties.
• HTML form submission — Explains which controls are included in a POST request.
• Controller actions and routing — Determines which server method receives a request.
• View models — Groups form fields into a typed C# object for validation and processing.
• Model validation and ModelState — Handles required fields and validation errors after posting.
• Guard clauses and early returns — Keep command-specific paths, such as Cancel, simple and safe.
• Anti-forgery tokens — Help protect state-changing MVC POST forms from cross-site request forgery.
• Post/Redirect/Get — Redirects after a successful POST to avoid accidental duplicate submissions.