Authenticated vs Unauthenticated Transactions

   Journey Manager (JM) The transaction engine for the platform.  |    System Manager / DevOps  |  All versions This feature is related to all versions.

Manager supports both authenticated or unauthenticated transactions.

When a transaction is authenticated, the user completing the transaction has logged into and been identified by Manager, usually by supplying a username and password. When a transaction is unauthenticated, the user completing the transaction has not logged in to and doesn't have an identity with Manager.

Manager provides similar features to both authenticated and unauthenticated users, but the features are implemented differently. There are different solutions available in both cases. It's important to understand that a transaction and a user are two different entities. There might be solutions where a SSO user account is created of a form transaction, for example, when you onboard a client and let them to work on other form tasks as authenticated users. In that case, you would create a user account record on the back of the onboarding or customer registration form transaction.

In other cases, unauthenticated clients access a public form available form a link on a customer's website, then submit the form, so no user account is involved at all and the forms are submitted as anonymous transactions.

There are many solutions where the relationship between a user and transactions are:

• 1 user : many transactions - an adviser onboards customers via Workspaces
• many users : many transactions - complex collaboration jobs with multiple parties participating in work
• no user : many transactions - public forms submitted by unauthenticated users

Form Pre-fill

Authenticated

Unauthenticated

When a user is authenticated, their identity, including the data stored about them in back-end systems, can be used to partially complete forms with information that is already known about them.

When a user is unauthenticated, data can be pre-filled by using request parameter prefill mapping, which allows pre-fill data to be passed to a transaction through HTTPHTTP ( HyperText Transfer Protocol) is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. request parameters, session attributes, or cookies. After that, any personal details from the form can be used to call a dynamic data service to recover all missing anonymous user data from a back-end system so the form is prefilled.

Form Save & Resume

Authenticated	Unauthenticated
When a user is authenticated, they can save a partially completed transaction and associate it with their identity. Later, if they log back into their account, the incomplete transaction will be available to them.	When a user is unauthenticated, the save and resume functionality relies upon a reference codeA reference number is a unique identifier assigned to each transaction., similar to an airline booking. Optionally, a security question can be defined to provide a basic layer of security.

Transaction History

Authenticated	Unauthenticated
When a user is authenticated, they can log into Manager to see a history of their transactions. Generally, they only see a summary of the transactions, as data retention policies will often result in the details being purged.	When a user is unauthenticated, one method of providing a transaction history is sending a confirmation email to the user once the transaction is complete.

Tasks

Authenticated	Unauthenticated
When a user is authenticated, tasks can be assigned to them in Manager. These tasks will then appear in their task list.	When a user is unauthenticated, tasks can be assigned to them by directing them to a dynamically generated URL. When they visit this URL, they'll be prompted to perform the task.

Best Practices

Based on the content covered in this topic, you might be wondering if it's better to use authenticated or unauthenticated transactions. As with most decisions of this nature, it depends on exactly what your organization is trying to achieve.

Consider the following details:

• Many organizations already have their own methods of authentication integrated with their back-end systems and would rather not introduce a new mechanism of logging in via a username and password.
• Users are often reluctant to sign up with a username and password purely for the sake of saving and resuming a transaction. If they're forced to register, many users will abandon the transaction.
• Identity — and specifically, the identity of customers outside your organization's firewall — can be difficult to implement. Manager does support industry-standard technologies, such as LDAPLightweight Directory Access Protocol (LDAP) is an open, vendor-neutral, industry standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol network. and Single Sign-OnSingle sign-on (SSO) is a property of access control of multiple related, yet independent, software systems. With this property, a user logs in with a single ID and password to gain access to any of several related systems. (using SAML), but these do add complexity to the implementation process.

We generally recommend the following:

• External customers should be treated as unauthenticated users. This may have an impact on the ability to pre-fill data in their forms, but this approach simplifies the integration requirements, the security implications, and the time to market.
• Internal users, such as help desk and call center staff, should be treated as authenticated users. This is usually simpler to implement as internal users will be already be authenticated on the network, and implementing LDAP or Single Sign-On is relatively straight-forward.

In some cases, organizations will require external clients to be authenticated, and as we've covered in this topic, this is most certainly possible. it will, however, affect both the time and cost of implementation.

Next, learn how to change the access type for a form space.