|This content applies solely to Appian Portals, which may require an additional license purchase.|
Every portal needs at least a portal object and an interface, but a portal can contain that and so much more. This page walks you through creating a portal, from the very beginning of development through deployment.
For more information on creating, publishing, and deploying portals see the Portal Object and Manage a Portal pages.
This walk-through uses record types to seamlessly connect your Appian data to your portal. This is the recommended way to work with data in a portal.
However, you can also write and query data using CDTs if necessary. And, if you have a publicly-available external database, you can directly write to or query from that database.
The portal object contains the settings that are used to publish a portal. When a portal is published, Appian bundles up the portal object and all the precedents of the portal object to create the portal.
To create a portal object:
Pages are the interfaces that display to your portal users. Similar to sites, you can have up to five pages in a portal and can choose one interface object to display on each page. If you have more than one page, they display in a header bar.
The interface you add as a page cannot contain rule inputs. However, it can reference other objects that use rule inputs. Also make sure that you aren't using any incompatible functions or components in your interface. For more information about the functional design considerations to keep in mind when creating a portal, see Portal Best Practices.
To add a page:
If you add more than one page to your portal, the header bar is automatically enabled. If your portal has only one page, the header bar is optional. Showing a header bar in your portal allows you to choose a color and logo to display in the header bar to help your users recognize that the portal belongs to your brand.
Additionally, you can make changes to any of the default branding configurations, such as input and button shape, to fit your organization's branding guidelines.
To configure the header bar and branding:
The Service Access section allows you to configure access to services using service accounts and/or Google reCAPTCHA.
A service account acts on behalf of your portal users. The records, processes, and documents stored in Appian won't be available in your portal until you give your service account access to them.
System administrators can create a service account directly from the portal object.
To add a service account:
Optionally, you can add reCAPTCHA to your portal to help you monitor your portal for spam or potentially malicious activity. Not every portal needs Google reCAPTCHA, but we recommend using it if your portal is high profile, highly publicized, or if you have had issues with spam messages in your portal.
To add a reCAPTCHA connected system:
See step 6 for more information on how to use reCAPTCHA in your portal interface.
You can configure your portal to be a Progressive Web App (PWA). A PWA looks and behaves like a native application and allows your users to install the portal on their device for easy and frequent access.
See the portal object page for more information about PWAs.
To configure your portal as a PWA:
This step will depend on your portal use case. This table lists common capabilities of portals along with the high-level steps to accomplish them.
|If you want your portal to…||Then…|
|Query data.||1. Create a record type.
2. Query the record type in a portal interface using a!queryRecordType().
Note: You cannot use a record type as a source for grids, charts, or card choices. You must use an Expression as the source and use
|Allow portal users to upload files.||1. Create a constant of type Folder for the folder that the files will be uploaded to.
2. In your portal interface, add a File Upload or Signature component. For the target parameter, use the folder constant.
3. In the saveInto parameter of a submit link or button, use the a!submitUploadedFiles()* function.
Note: Uploaded files can be no larger than 10 MB.
|Allow portal users to download or view files.||1. In your portal interface, use the a!documentDownloadLink, a!documentImage, and/or a!documentViewerField components.
2. In the document parameter of the components, use a constant of type document or a document ID.
|Add, update, or delete record data.||1. In a saveInto parameter on your portal interface, use a!startProcess().
2. In your process model, use the Write Records and Delete Records smart services.
|Create a user, update data using a CDT, send an email, or start another Appian process||1. In a saveInto parameter on your portal interface, use
2. In your process model, use the appropriate smart service.
|Use reCAPTCHA to determine what to do if a bot is likely trying to use your portal.||1. Create and add a Google reCAPTCHA connected system to your portal.
2. In a submission button on your portal interface, use the a!verifyRecaptcha()* function in the recaptchaSaveInto parameter.
Whenever the submission button is used, Google reCAPTCHA returns a score that determines how likely it is that a bot is trying to use your portal. Configure the
a!verifyRecaptcha() functions will not work outside of a published portal. In order to test these functions, you must publish your portal first and test it in the published portal.
Service accounts act on the behalf of your portal users. Unless the service account is given explicit permissions to certain objects in Appian, your portal won't have access to the records, processes, and documents stored in Appian. This helps keep your Appian environment secure and ensures your portal users can still connect to the information and processes that are important to them.
To give the portal service account the appropriate permissions:
With your supporting objects and portal object all created and configured, your portal object is now ready for publishing!
To publish your portal object:
For more information on publishing, see Manage a Portal.
Now that your portal is published, it's time to test it. It's important to test both your individual objects and the published portal as a whole with production-level usage. Some connections can't be tested until after publishing.
Navigate to the published portal using the URL under Web Address and test your portal as a user would interact with it.
To make sure that everything is functioning correctly, fully test all of the objects and connections that are precedents of your portal, including the following:
Be sure to fill out all of the fields, whether they are required or not, and go through all of the steps in your portal. If you run into any issues while testing, check out the Visitor Activity Logs in your portal object.
For more information about testing and to learn about who can see your portal during testing, see Manage a Portal.
If you found any problems with your portal during testing, go ahead and make the necessary changes to your objects. When you save changes to your portal object or portal object precedents, the portal automatically republishes to stay up-to-date with the latest changes.
For more information on automatic republishing, see Manage a Portal.
Once you've created, published, and tested your portal object, it's time to deploy your portal to the next environment.
When you deploy a published portal, it automatically publishes in the target environment. To make sure your portal publishes automatically when you deploy it, see Deploying a portal for important information.
To deploy your portal:
You're ready to go!
Congratulations! You created a nice and shiny new portal!
After a successful deployment to your production environment, you can now share your portal with your users at the web address specified in the portal object and celebrate.
On This Page