Portals vs. Public E-Forms
There are two basic ways to interact with external users – Portals and Public E-Forms. Both have their benefits and uses but both have different requirements and outcomes. So the question is “When do I use Portals vs. Public E-Forms?” In order to answer that we will explain what they both are and what they do. From that we will then explain when to use each.
Portals
Portals are a great way to present a defined set information to external users as well as to request a specific set of information from external users. We have a 4-part series of articles on Portals and how to configure them. The first part is here and is I highly recommend reading the entire series to get a good feel for the capabilities of Portals. The important thing to talk about in regards to “when to use portals” is how they are initiated and how they interact after they are started.
Portal Example with Required Documents and Forms
Portals are initiated in one of two ways. First, they can be started manually by an internal user when they determine they need some information presented externally. Second, workflow can be configured to start a portal when a specific trigger even happens. Notice that both ways require something internal to start the process. This is very important as we will show later.
Another aspect of Portals that will dictate when they are used is that Portals typically work in conjunction with existing Records in the system. You relate a Portal to a Record so that all the information presented and submitted comes from and goes into that specific Record.
Public E-Forms
Public E-Forms are great for collecting information from outside users. The data from the form can be specific and structured and can be allowed to come into the system, create Records, trigger workflow and more. We have a great article on Designing E-Forms as well as several articles that refer to uses for E-Forms.
Public Electronic Forms Examples
Public E-Forms are initiated by outside (public) users going to the web link to open, fill out and submit the form. Typically you would have a link or button on your main Web site that takes the user to the e-form page. Or you might include the link in a marketing email blast that people can click on to fill out the form. Either way, the act of opening of the link and filling in the form requires something external to start the actual data gathering process.
Another aspect of Public E-Forms that will dictate when they are used is that Public E-Forms typically work by creating new Records in the system when they are submitted. The information from a Public E-Form is used to create the new Record and any attachments from the form are saved into that Record as well. There are exception where you can link a Public E-Form to an existing Record but normally when that happens you would be better off using a Portal instead.
Portals vs. Public E-Forms Revisited
Now that you know more about the basics of when Portals and E-Forms are started you may have already put 2 and 2 together on when to use each. It is really fairly straight forward. Portals are started by an internal process (internal user or workflow) and Public E-Forms are started by an external process (public user). If you can control the start of the process then you are better off using a Portal. If you do not control the start of the process then you are better off using a Public E-Form. Also, if you are dealing with an existing Record in the system then you will normally use a Portal. However, if the transaction will create a new Record then you might opt for a Public E-Form.
Scenarios
Here are some example scenarios that might help demonstrate the differences:
Scenario 1: You want to be able to respond to requests for information from your Web site. This calls for a Public E-Form that can be configured to post the information into docMgt and kick off a workflow.
Scenario 2: You want to ask an existing customer to supply some missing biographical information. This calls for a Portal that embeds its own Public E-Form requesting the information. The form can be pre-filled with existing data and the customer can validate, update and add information as needed.
Scenario 3: You are a real estate agent and your process requires specific documents to be submitted for specific types of sales. This would most likely utilize both Public E-Forms and Portals. You would use a Public E-Form to start the process by allowing the potential client fill out the e-form from your web site. This form asks which property they wish to buy and some other basic information. The form is submitted and creates a Record in docMgt and starts workflow. Based on the type of property requested you may need to request follow up documents that show financial ability, residency and so on. The workflow would detect this and automatically create a Portal that requests the proper documents. That Portal is then automatically sent out to the initial buyer to be completed.
Summary
Hopefully this helps in showing when to use Portals vs. Public E-Forms. The rule of thumb is that internally-controlled processes start with Portals and externally-controlled processes start with Public E-Forms.
Related Links
- Collaboration Portals Pt. 1 – Simple Document Sharing
- Collaboration Portals Pt. 2 – Advanced Features
- Collaboration Portals Pt. 3 – Templates
- Collaboration Portals Pt. 4 – Sharing Multiple Records
- Workflow Part 3 – Action Types
- Designing E-Forms