Support Portal ContactGet in touch

Whats in a Postback

   Words by CRM Consultancy

   on 03/11/2015 08:30:00

ASP.NET v4.5 StackThe original Web Forms implementation of ASP.NET was designed in some ways to mimic (at the time!) traditional Win Forms development in attaching code-behind events to controls on the Web Form Page – in this way the .NET Framework could worry about loading the page and passing the sequence of execution to the code for the event triggered by a control.




So if examine the following mark-up:


We can then see the web-page running the following event code when the page posts back in response to the button being clicked:

protected void SaveAndConfirm_Click(object sender, EventArgs e)

However, despite this familiar pattern, Web Form development is not the same as Win Form development.

Win Forms communicated directly from the Form running in memory to the Event – whereas Web Development (putting AJAX and other inline communication methods to one side) works in a much more Client-Server model, and in this tracks a much more defined Request going to the Server followed by the Response coming back from the Server.

Initially for static HTML Pages,this request could be limited to a single URL Request where the client asks for the content at a certain URL Address and the corresponding server would respond; and in some ways, browsing the web today can still fit into this pattern.

However for Web Applications and particularly Web Forms we often want the user to supply some return information back to the Server; and so want to include a bag of additional return values in the Request that is passed to the Server, such that the Server can then take these values and perform some kind of server-side logic using the details supplied.  This give us basic HTML Forms.

From this Microsoft incorporated the concept of a Postback into the (then) new ASP.NET Framework as way formalising the submission of HTML forms in a way that fitted with the existing Win Forms pattern – summarising a block of .NET Web Controls into a block of values that could be posted back to the Server as Request Variables or Viewstate, including variables on which Events or Triggers to run as the page finishes posting back on the server.  In this way, the ASP.NET Framework connects the Event defined on a Control (in the above case, the OnClick Event) to a block of server code-behind that then implements whatever logic that clicking the button should entail.

However, if we strip back this Postback and look at how this operates, we can see that at run-time the ASP.NET Framework works by adding the following Javascript to the Form:

var theForm = document.forms['form1'];
if (!theForm) {
    theForm = document.form1;
function __doPostBack(eventTarget, eventArgument) {
    if (!theForm.onsubmit || (theForm.onsubmit() != false)) {
        theForm.__EVENTTARGET.value = eventTarget;
        theForm.__EVENTARGUMENT.value = eventArgument;

This then prompts Javascript to populate 2 hidden textboxes that the ASP.NET framework inserts into any Web Form Page:

<input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />

Which the Framework then posts back to the Server as part of the Response coming from the client form submission.

The ASP.NET Framework then processes these request values and looks at the ‘__EVENTTARGET’ value in particular to determine which event has triggered the Postback, and so which server-side trigger to call in response at the server-end of the request.

So far so good in understanding what the framework gives us – but we can see this really in action by building our controls which use this framework.

If we examine the following:

<input id="html_input_saveconfirm" onclick="__doPostBack('SaveAndConfirm', '');" type="button" />

This is a standard HTML Control that is then going to call the ASP.NET Postback method via Javascript – and notably, call the event with the ‘__EVENTTARGET’ attribute supplied with a particular event value.

Initially this will do nothing at the server-side, as the ASP.NET Framework will simply load the page in the usual fashion and ignore the Event Target that the page has requested (as postback) from the server due to the lack of an Event Handler.

However we could then add our own Event Handler into the central page method for Form_Load.

protected void Page_Load(object sender, EventArgs e)
    string eventTarget = Request.Form["__eventTarget"];

    if (Page.IsPostBack)
        if (eventTarget.Equals("SaveAndConfirm"))

private void Event_SaveConfirm()

This then builds a simple custom event handler that replicates the ‘behind-the-scenes’ action of the .NET Framework.

Why is this important?

This look at the .NET Framework and Postback is increasing a look into the past, as the concept of posting a form in a traditional Client Request / Server Response is increasingly inadequate for the rich UI Enabled Web Applications of today. (although you can easily argue that under-the-bonnet everything still is a client request, server response of a kind)

However this concept of Postback underpins not only the Full Postback model of ASP.NET v2, but also the Partial Postback Model of Update Panels and other AJAX Framework Controls built into ASP.NET v3 and v3.5, and even in the MVC-Enabled world of ASP.NET v4 and v4.5 is still the backbone for building ‘low-tech’ Web Applications.

With the advent of ASP.NET 5 and Web API, the core framework behind Web Forms is being replaced with a more responsive smaller request smaller response model for Web Development based on MVC – however the key to understanding why this newer model is relevant and required is in understanding the limitations of previous Frameworks; in the same way understanding why Web Forms were important in replacing legacy ASP and old HTML forms as the defacto standard.

That and until existing projects are moved over, a large part of the world that is not working in PHP is still running, supporting or developing in Web Forms – so understanding what came before is often key in understanding what comes next.

How does this apply to Dynamics CRM?

Well, back in the day, version 1.0 of Dynamics CRM was the first Microsoft Application to be built entirely on the then new ASP.NET Framework – and so CRM and .NET have sort of ‘grown up together’ in many ways, with each new version of CRM using a newer version of the framework.

In this sense, understanding ASP.NET is very useful for having a deeper understanding of CRM itself and is key to building Portal and other Web Applications that then work alongside CRM.

Dynamics CRM Version .NET  Framework Version
CRM v1 and v1.2 Version 1
CRM v3 Version 2
CRM v4 Version 2
CRM 2011 Version 4
CRM 2013 Version 4.5
CRM 2015 Version 4.5


Further Reading

There is no shortage of articles exploring the .NET Framework, however the following article is an excellent overview of Web Form’s place in the world alongside MVC, and how this is changing with ASP.NET v5.

Share this Article

Search Articles

Filter Articles

CRM Tech DocMan

Recent Articles

CRMCS Quick Start Guide: How To Produce a Microsoft Teams Live Event Dynamics 365 Marketing: Lead Scoring and Sales Acceptance Designing and Developing Microsoft Power Apps Portals Thank You for Attending CRMCS’ Webinar - Achieving B2B sales excellence with Dynamics 365 & Microsoft Teams Thank You for Attending Our Webinar - Achieving B2B sales excellence with Dynamics 365 & Microsoft Teams Webinar: Discover How CRMCS Have United Dynamics 365, SharePoint and Microsoft Teams To Create Sales Excellence Ignite your workflow by adding DocDrive365 to Office 365 The CRMCS guide to everything you need to know about integrating Teams with Dynamics 365 Saving Time By Keeping Documents In One Place TDE Database Encryption with On Premise Dynamics The Key to Successful Compliance in 2020 Part 2: Let’s get GDPR Compliant with Microsoft Power Automate Top 3 Essential Tips for Remote Working Dynamics 365 Marketing: Top 5 Best Features Dynamics Day in the Life - Puma Investments Can you use Teams to amplify collaboration in Dynamics? Part 1: Using a Scheduled Power Automate to Trigger Expiry Date Reminders The secrets of successful document collaboration in Dynamics CRMCS launches new AppSource approved DocDrive365 Dynamics Day in the Life - Moneypenny Release Management Add the App to Dynamics DocDrive365 Security: Day One - Getting Started with Dynamics to SharePoint Permissions Building a New Scheduled Process using Flow
  • "Paul has made a real difference to how my team of 24 people record and store valuable customer data and sales opportunities. Highly recommended."

    James, Operations Director

  • "Understanding your business allows us to advise when to implement aspects of CRM and, likewise, when not to."

    Paul McQuillan, Managing Director

  • "Dynamics 365 and CRMCS have made a real lasting difference to our business, allowing us to replace older systems that were holding back our performance."

    Grahame, Chief Operating Officer

  • "James worked well with us to help connect CRM with Outlook and relate how this might benefit our team using CRM for Property Care."

    Natalie, Property Care Supervisor

  • "Matt was really good with helping us run User Testing on the new Compliance Module of our CRM System."

    Tom, Compliance Administrator

Prefer to go old-school?

Write to us using the below addresses.

Head Office
CRM Consultancy
61 Oxford Street
M1 6EQ

London Office
CRM Consultancy London
Grosvenor Avenue

Content © CRM Consultancy.