How to Differentiate Draft and Submit on a PowerApps Portal Form

Overview

Building on the Locking Forms after Submission post, let’s explore how we can use the same idea to implement a “Save as Draft” feature to complement the “Submission” functionality. This can come in handy when the form is long or tedious, but you still want to know when the user has completely finished entering all of the data. Web Forms have a place here as well, especially when data entry needs to follow a step-by-step flow. However, my personal preference is to use Entity Forms due to various issues I’ve experienced with Web Forms over the years – but this post isn’t intended to make an argument for one over the other.

To do this, I’ve set up my pages and forms slightly differently.

The Setup (Building on the Previous Example)

This section is for anyone who has followed along with the aforementioned example, based on the Proposal entity I created.

The first thing we want to do is remove the Entity Form Metadata that saves the Status Reason on submission. From now on, we will need to drive that change using a different field and a different methodology.

I’ve added a few other changes, but rather than break them all out, here is an overview:

1. I’ve created a Web Page with the Partial URL of “new” as a child of the Proposals page
   • It uses the same Entity Form and Page Template as before, with the idea being that it would be our “create” page
2. I’ve updated the Entity List on our Proposals Web Page to point to this new Web Page
   • When someone creates a new record from the list, they’ll be taken here instead
   • This page shares the same Entity Form as before, so it will still redirect to our Submission page on completion
3. I’ve updated the “Proposal – Create” Entity Form to point to a new tab, which accepts our bare minimum requirement – in this case, the Name of the Proposal
4. I’ve added some new fields and relationships to better prove out the process
   • “Created By (Contact)”, Lookup to Contact – set by the Insert Entity Form
   • “Modified By (Contact)”, Lookup to Contact – set by the Edit Entity Form, via Entity Form Metadata
   • “Key Contacts”, N:N relationship between Proposal and Contact – this helps us drive permissions and have a relationship to the Proposal to showcase
   • “Submitted On”, DateTime – this is how we track submissions

The Approach

Ultimately, we will do the following:

1. Clone the “Update” button
2. Turn the cloned button into a “Save” button
3. Attach an event to the Submit button in order to fill our hidden date field when pressed
4. Use a real-time process (workflow or plugin) to update the Status Reason field when the date field is changed
   • If there’s a date, change to Submitted
   • If there’s no date (such as a reversal in Dataverse to allow further updates Portal-side), change to Draft
   • Using a real-time process will force the Portal to be aware of the change

I typically hide fields by adding them to a Section (with the section label hidden), naming the Section something like “hiddenProposalData”, and using the CSS I’ve shared on the Code Snippets page.

The Real-Time Process

For this example, I’m going to use a Real-Time Workflow. To implement this, I start by switching to the classic view of my solution.

1. From here, I’m going to create a Real-Time Workflow for the Proposal table
2. The triggers are on Create & on Update of my “Submitted On” field (field not shown selected in image)
3. Despite the image, the scope should be Organization
4. Add the logic to check whether Submitted On has data – if it does, set the Status Reason to “Submitted”; otherwise, set it to “Draft”

The JavaScript

Next, I add the following JavaScript to the Proposal (standard) Entity Form. If it’s added to the Web Page instead, it will still be fine – jQuery won’t throw any errors in the chain for Insert (which uses #InsertButton) or Read-Only (no button).

This will clone the Update button, change the cloned button’s class, and add the appropriate onclick code to either add (Submit) or remove (Save) the hidden date that triggers the process.

Both are important in case a user attempts to Submit, hits a validation error, and then tries to Save – if we only applied the code to the Submit button, the date would still be filled and would trigger our process.

There are more sophisticated ways to solve this, but for the sake of the example we will keep it simple.

$(document).ready(function () {
    var $updateBtn = $("#UpdateButton");
    var $saveBtn = $updateBtn.clone();
    $saveBtn.attr("id", "SaveButton")
        .attr("onclick", "$('#new_submitdatefield').next('div.datetimepicker').datetimepicker().data('DateTimePicker').date(null);" + $updateBtn.attr("onclick"))
        .removeClass("btn-primary")
        .addClass("btn-default")
        .val("Save")
        .insertBefore($updateBtn);
    $updateBtn.attr("onclick", "$('#new_submitdatefield').next('div.datetimepicker').datetimepicker().data('DateTimePicker').date(new moment());" + $updateBtn.attr("onclick"));
});

End Result

Below you will find examples of this process in place. For some of the more complicated problems this can present, I will try to keep the Considerations section updated as I come across more.

Considerations

Being able to save the form without submitting it is helpful – unless it’s too inconvenient to satisfy all of the required fields and other conditions put in place. Having had requirements along the lines of “there needs to be at least N rows in each and every subgrid” as submission criteria, I know that such requirements can get extensive. Here are some options to help alleviate this:

1. Add/Remove Dynamic Validations
   • I’ve provided some decently flexible code samples on the Code Snippets page that can very easily add and remove validations on fields and sections
   • Remove the Required logic on click of the Save button, then allow the function to proceed
2. Dynamic Validations & Validation Groups
   • Look to add these validations to specific validation groups, then check those validation groups as part of your entityFormClientValidate function
     • E.g., only check this group if the triggering event is the Submit button, not the Save button
3. Dynamic Validations & Custom Validation Functions
   • Consider adding a custom validation function that checks for a specific class or attribute value on the element – such as data-validate, which you set/unset on click of Save without removing the validation itself