Portals - How to create "second" Interface/Portal revealed after code/creditentials input on initial Portal page?

I managed to create Interface that will "showWhen" (visibility is set to a condition) and it works fine. On start, the Portal only shows the field for code input, after I submit correct code, it reveals the hidden components. 

What comes to my mind, is this "hidden" component truly hidden? I mean, is the data secured?

When I enter DevTools (by clicking F12), in the web elements, the hidden elements are missing, until they are revealed. Does this mean they are secured and cannot be entered/seen/copied etc until I submit my code? 

Also another question is about Portal Interfaces. 

Appian docs mentions  about Initial Interface and Secondary Interface, where in the Initial we cannot use Rule Inputs, and in the Secondary we can use them. Am I understanding that correctly, that my Initial Interface is the one with field input, and Secondary is when the rest components are revealed? As an object, it is still a single Interface but with visibility options. Can someone enlighten me what really are Initial and Secondary Interfaces and how to properly create them (in case I am doing it wrong)?

Hi Marcin! I'm a product manager at Appian working on Portals features. The answer to your first two questions is "yes" -- based on the showWhen configuration you described, the data in the component would be hidden and would not be seen until you submit. 

To answer your last question, the primary interface is what gets added to the portal object in Appian Designer and the secondary interface(s) are all the interfaces nested within that primary interface. It behaves similarly to nesting interfaces when you're designing interfaces outside of Appian Portals as well, if you're familiar with that design pattern (i.e., calling an interface using rule! in the expression of another interface). Depending on your configuration, the end-user shouldn't be able to tell what the primary vs. secondary interface(s) are. 

We are actually working on a couple upcoming features this year to make this design experience simpler. One is allowing portals pages so that you can add more than one interface directly to your portal object. Another is allowing rule inputs in your portal interfaces so that you don't have to use secondary interfaces to work around that. 

Please let me know if you have any follow up questions or other feedback on Appian Portals! 

Hi Marcin! I'm a product manager at Appian working on Portals features. The answer to your first two questions is "yes" -- based on the showWhen configuration you described, the data in the component would be hidden and would not be seen until you submit. 

To answer your last question, the primary interface is what gets added to the portal object in Appian Designer and the secondary interface(s) are all the interfaces nested within that primary interface. It behaves similarly to nesting interfaces when you're designing interfaces outside of Appian Portals as well, if you're familiar with that design pattern (i.e., calling an interface using rule! in the expression of another interface). Depending on your configuration, the end-user shouldn't be able to tell what the primary vs. secondary interface(s) are. 

We are actually working on a couple upcoming features this year to make this design experience simpler. One is allowing portals pages so that you can add more than one interface directly to your portal object. Another is allowing rule inputs in your portal interfaces so that you don't have to use secondary interfaces to work around that. 

Please let me know if you have any follow up questions or other feedback on Appian Portals! 

Hi Marcin, 

I wanted to further clarify my answer. If you're concerned about inadvertently exposing something to the wrong users through using a showWhen expression, we'd recommend using record-level security (configured on the record type) instead or omitting that data from your portal altogether if it's not absolutely necessary to your use case. 

Hi Elizabeth Hall!

I just wanted to make sure I understood correctly what you wrote regarding " allowing rule inputs in your portal interfaces so that you don't have to use secondary interfaces to work around that".

Does adding rule inputs to primary interface means you'll enable the use of parameters in Portal's URL to be passed as rule inputs to Portal interface thus allowing to pre-populate the interface using parameters?

Thanks!

Hi Zoran, 

Being able to pass rule inputs into a portal via a URL is a high priority use case that our team is currently exploring. Do you have a specific use case for this capability and if so, would you mind sharing? 

Hi Elizabeth!

The use case we have is pretty simple.

A few IT systems/applications provide public access to client's (electronic or paperback) publications.

The client would like to allow users accessing those systems to submit a request for copyright permission (reusing the data or the content from the publication).

The request should be initiated directly from the site on which the publication is found.

When the user clicks on a link, the site should send initial data about the selected publication (so the user doesn't need to enter it manually) to Appian Portal which will be used to submit the permission request.

Hi Elizabeth,

I have a question for you
if I am using multiple pages in one portal using your method of calling the next page with rule!, 

suppose I have a form on the second interface, and its values are stored in local variables on that form interface.

So how can I take that values to the next page with rule! , because I need that values to call some API on further pages

Hi Vijay, 

You would need to have a local variable on the parent interface which holds the value and then use rule inputs on the child interfaces to pass value around. For example, something like this: 

  local!page: 1,
  local!record,
  a!match(
    value: local!page,
    equals: 1,
    then: rule!firstInterface(
      record: local!record
    ),
    equals: 2,
    then: rule!secondInterface(
      record: local!record
    ),
    default: {}
  )
)