Manage a Portal

The capabilities described on this page are included in Appian's standard capability tier. Usage limits may apply.

Overview

Making continuous improvements and updates to your portal is important to ensure the best possible experience for your users. To make your portal available to your users, you'll need to publish, test, and deploy your portal.

Publishing a portal

A portal consists of a portal object and at least one interface object. The interfaces contain the content for the portal object, displayed as separate pages. The portal object contains the settings used to create the portal.

When you publish a portal, Appian bundles up the portal object, the interface, and all of the objects used by the interface, and publishes them all as a cohesive serverless web app at a unique URL.

Publishing a portal makes it available to your users at the specified web address. This means that anyone with the URL can access your portal. For more information, see Who can access a portal during testing?.

You'll only be publishing a portal directly during development. If you've published the portal in the source environment, Appian automatically applies that publishing status to the portal object in the target environment after you successfully deploy the object. No extra steps required! For more information, see the Deployments and publishing and Determine the best time to deploy to production sections below.

To make your portal available to users or for testing, follow these steps to publish your portal:

Open your portal object.
Under Configurations, toggle on Published.
Click SAVE CHANGES. The portal won't begin publishing until you save.

If you no longer need for your portal to be available to users, you can easily unpublish the portal:

Under Configurations in the portal object, toggle off Published.
Click SAVE CHANGES. The portal won't be unpublished until you save.

Updating and republishing a portal during development

Once your portal is published, we automatically republish it when you save changes to your portal object or portal object precedents. This ensures that your published portal is up-to-date with your latest changes and ready to test.

Though it is usually unnecessary, you can still manually republish your portal at any time. There are three scenarios when you may want to manually republish:

If there are updated admin console settings that need to be reflected in your portal.
If you have made changes to group properties or group membership for any group that your portal uses.
If you need to cancel the publish that is in progress and immediately publish the latest changes to your portal precedents.

To manually republish your portal:

Open your portal object.
In the blue status banner, click Republish.

Automatic republishing with environment updates

We will also automatically republish your published portals after your environment is restarted, such as when it is upgraded or hotfixed. This ensures your portals will reflect security updates and performance enhancements right away.

Automatically republishing portals that link to other portals

To help keep links to your portals up-to-date, we automatically republish portals that use a!urlForPortal() to link to other portals when the following occurs:

In the linked portal, the web address identifier for the portal or a portal page is changed.
In the linked portal, the Encrypt URL Parameter checkbox is selected or deselected in a portal page.

Testing a portal

As with all Appian applications, you should always fully test all objects that your portal relies on to make sure everything is functioning correctly. Be sure to test everything in your portal interface, including all input and selection fields, and connections, queries, and processes.

After you've tested all objects and connections for your portal in Appian Designer, it's important to fully test your portal after it is published. 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.

This will help mitigate the following concerns:

The a!submitUploadedFiles() and a!verifyRecaptcha() functions only work in a published portal. You can't test them in the interface object itself. See Configuring reCAPTCHA for more information about how to test reCAPTCHA.
If you are using an integration to connect to Appian and it isn't set up properly, you may not notice until after you publish and test the portal. When you're testing the interface object in Appian Designer, the integration connection may still work, even if it isn't set up correctly.
The best way to make sure you are only using compatible capabilities, is to fully test the entire portal.

Additionally, be sure to fully test all parts of the connections to your portal with a production-level data and usage. This includes all web APIs, integrations, and connected systems.

See Configuring reCAPTCHA for additional information on testing reCAPTCHA.

Who can access a portal during testing?

You must publish your portal to fully test it, which means that anyone with the web address can access your portal, maybe even before you're ready for them to.

To help limit access to the portal while you're testing, UUIDs are added by default to the web addresses of all portals in your development and testing environments. This means that only users that you share the URL with will be able to easily find the portal during development.

In production environments, this option is deselected by default to make the web addresses more intuitive and easier for your users to access them.

This setting can be changed in the Administration Console.

Deploying a portal

You can easily deploy a portal from one environment to another as a part of your existing deployment pipeline. Simply deploy your portal object as part of a deployment package or application. Make sure to include all precedents of your portal object with your deployment.

For more information on packages and deployments, see:

Deployments and publishing

As with all objects, when you deploy a portal object all of the fields and configurations are deployed with it. After deployment, the value of the portal object's Published field in the target environment will be the same as the Published field value in the source environment.

For example:

If the portal is published in the source environment, it will be published in the target environment.
If the portal has never been published in the source environment, it will not be published in the target environment.
If the portal has been unpublished in the source environment, it will be unpublished in the target environment.

When deploying a published portal, the portal will automatically publish in the target environment during deployment.

If your portal is published in the target environment and you deploy an updated precedent of the portal to that environment, the portal will automatically republish after import to include the latest updates.

Determine the best time to deploy to production

For production environments, we recommend deploying portals during off-peak hours. When a portal is republished, users interacting with your portal may encounter errors or lose any work in progress. This will happen even if the portal is updated because of a precedent change.

Import customization files for portals

In some cases, you may need to provide connection information in an import customization file (ICF) when deploying portals. This table outlines the information you may need to provide in an ICF.

If your portal uses…	Don't forget!
Integrations and Web APIs to write or query data	ICF with API keys
Querying or writing data directly from a publicly accessible external database	ICF with data source connected system credentials
Google reCAPTCHA connected system	ICF with connected system credentials
Environment specific constant	ICF with value of constant
Integration to external system	ICF with connected system credentials

Setting up service accounts before deploying published portals

In order to publish your portal automatically after deployment, you need to create a portal service account with the required permissions in your target environment.

Before deploying your portal you must perform the following in each environment in the deployment pipeline:

Deploy all groups that you are using in your source environment to grant your service account access to your portal and objects.
Create a service account with the same username as the portal service account.
Set up group membership for the service account to match the source environment.

Feedback

Was this page helpful?