Outputting a User's Secure Zones can help them to keep track of services they're signed up to.
This Layout must be outputted inside a Page protected by a Secure Zone
You can use the following links to learn how to set up a Secure Page and the means to access it:
Outputting a User's Secure Zones can help them to keep track of services they're signed up to.
<div data-gb-custom-block data-tag="include" data-0='user_secure_zones' data-1='default' data-2='default'></div>
Parameters:
layout
You can find the user_secure_zones
Layouts at the following path in Code Editor: layouts/modules/module_5/user_secure_zones/
Inside this folder, a single Liquid file can be created to act as your Layout. There is no "wrapper" and "item" file needed for this kind of Layout.
You'll need to use a Liquid For Loop to loop over the records in this Layout.
One of the benefits of this is that you can rename the variable under which your fields are kept. If you like you can store the variables under the namespace "this".
Or, if you want to output the form_submissions
layout inside a user_details
Layout for example, you can store the variables under a different namespace e.g. case and continue to use this
to refer to the user_details
(Liquid variables are always inherited by Layouts included within them).
In the following examples, we'll use the namespace "secure_zone", but you can substitute this for the namespace you chose when creating your loop.
{{secure_zone.name}}
- The User friendly name for this Secure Zone.
{{secure_zone.id}}
- The ID of this Secure Zone
These features allow users to change the key information that identifies them on your site.
Install the Secure Zones Module
Users must remember their existing password
Users must be already logged in
This Article shows how Users who remember their Email address and Password can change these using a Form. If you need a feature for Users who have forgotten their password, try the Password Reset feature.
Create a Form which will be used to update Users' email address or password.
This Form should have a Secure Zone attached- but this can be an existing Secure Zone that you use for Accounts e.g. "My Account" or an equivalent.
You do not need to add any custom fields in the Siteglide Admin in order to use this feature. Instead, the feature will be added solely in the Form Layout.
You may wish to use one Form for updating an email and a separate Form for updating password. This is fine- just adjust these instructions accordingly.
We'll need to modify the Form Layout, so head to Code Editor and create a new Form Layout liquid file. This should be in the same folder as the Form you created in step 1.
You can add your Form to any Page.
Select your Custom Form Layout you made in step 2.
Editing email and password will only work if the User is already logged in. We recommend adding a Secure Zone to your Page to ensure this is the case.
In this step we'll be adding fields to the Form Layout which will allow the User to submit new email and password values.
Pay close attention to the IDs of these elements, as this is what Siteglide will use to identify them.
Purpose - In this field the User will submit a new value for their email address.
Purpose - In this field the User will submit a new value for their password.
On most Siteglide Forms you'll see an email address and password fields with the HTML ID s_email
and s_password
. These fields are specifically used for Users to enter their current email address and password.
Notice that the fields below we use for Users to provide new values for their email and password use different IDs s_email_edit
and s_password_edit
.
Remember, you do not need to use a single Form to edit both email and password. You can include these on separate Forms if you wish.
You can use custom JavaScript to show or hide the fields when needed. Only when a value is given to the fields will they validate and throw an error if there is a mistake.
Things to check at the end of this step:
The ID attribute of each field will need to be exactly the same as that used in the documentation in order to work.
The fields should not have an HTML name
attribute. This is because we don't wish the information to be stored in the Case along with other custom fields.
In order to use this feature the User must:
be already logged in
enter their existing password again
In this step then, we make sure we are giving the User the opportunity to re-enter their password:
The Form Default Layout already includes this Field- however it is hidden from Users who are logged in. The simplest way to complete the step is to remove the logic:
Things to Check
Make sure any <label> tags clearly show which field should be used for current password and which should be used for the new password.
Make sure the current password field is only included once in the Form Layout
The last thing the User wishes to do is to reset their password to the wrong value.
To provide extra validation, you can add confirmation fields:
Once you've added a confirmation field, our validation will make sure the email fields match and that the password fields match.
If you choose not to add a confirmation field, it will not be required.
To help the User's browser to understand the difference between current and new password fields, you could add values to the autocomplete attribute:
autocomplete="current-password"
autocomplete="new-password"
And you're done!
You can use this feature along with our other Front-End CRM features to give Users control over their Data and Credentials on your Site.
The user_details Layout contains the User's name, email and Custom Field Set Data. It can also be used as a container for other CRM Layouts.
This Layout must be outputted inside a Page protected by a Secure Zone
You can use the following links to learn how to set up a Secure Page and the means to access it:
The user_details
Layout contains a {{this}}
object with the basics of the User, as well as details that have been added to the CRM record via Custom Field Sets.
As such, it can be useful (though it is optional) to use this Layout as the container for all other CRM Layouts. This allows other Layouts e.g. user_secure_zones
to also have access to both their specialist data and the more general User data, allowing you to build more complex Layouts.
`
`
Parameters:
layout
- Choose a Layout to use.
You can find the user_details
Layouts at the following path in Code Editor: layouts/modules/module_5/user_details/
Inside this folder, a single Liquid file can be created to act as your Layout. There is no "wrapper" and "item" file needed for this kind of Layout.
{{this.name}}
{{this.first_name}}
{{this.last_name}}
{{this.email}}
{{this.created_at}}
- The date the User first signed up or submitted a Form on the Site
{{this.updated_at}}
- The last date the User's CRM data was updated
{{this['Company']}}
- An array of Companies this User is connected to
{{this['Address']}}
- An array of Addresses stored against this User
Inside a user_details Layout, you can access custom CRM fields by using:
{{this.properties.user_field_1}}
- To get the Field by it's field ID
Accessing Custom Field Sets will depend on the Custom Field Set data you have set up on your Site. Each Custom Field Set has a unique ID number assigned to it, and data is organised based on this number.
Custom Field Sets allow you to store custom fields directly against a Module Item. In the case of the CRM, they are used to store fields against a User which can be kept up-to-date. You can learn more about Custom Field Sets here.
In the following example, I'll be accessing data from the Custom Field Set 3 (Profile). You can use this example and replace the ID 3 for the ID of your Custom Field Set.
{{this.custom_field_sets.cfs_3.cfs_name}}
- The name of this Custom Field Set
{{this.custom_field_sets.cfs_3.properties.cfs_field_3_1}}
- The first field of the Custom Field Set. Replace the ID number at the end to fetch any field.
You may find it more helpful to output your available fields as JSON and use this to write your code.
Outputting {{this}}
will fetch the data as JSON, e.g.
Users can "add" or "remove" their favourite WebApp and Module items. You can display them to the User in Lists.
You have added a User Sign Up Form
A User has logged in
Possible Use Cases for this feature include:
A wishlist of Products
Bookmarks of favourite Pages
Giving feedback on parts of a Site the User found helpful.
This Layout will allow the User to add or remove an Item from their favourites.
The User Favourites Toggle Layout will only work within an item.liquid file (for Modules) or a WebApp Layout file that has access to {{this.id}}.
Use this Liquid to include your User Favourites Layout, the only parameter that'll differ for this is the "layout", here you can specify a custom layout: `
`
is_favourite
- you can use this within user_favourites_toggle
layouts to determine if the Module/ Webapp item is already added to the Users favourites like so:
Our default Layout contains two buttons which we'd recommend you use for reference when setting this up. Let's have a look at these buttons and what they're doing:
To keep things simple, we've bundled the arguments you need to pass into the function into a single Liquid variable containing a JavaScript array {{this.favourite_item}}.
If you need to modify them, you can split this into following the 4 items in the JavaScript array:
You can also pass success/ failure functions to the add/ remove buttons.
Available arguments for success callback functions:
type - add/ remove
- whether item was added or removed from favourites
name
- name of item added/ removed
button_element
- element that fired toggle function
*Available arguments for error callback functions: *
error
- error message detailing why function failed
If you add an error function, you must add a custom success function.
Note it's important to only add the names of functions at this step- this means without the usual round brackets which would contain arguments- that's because we only want to store the functions now and call them later.
You may want to hide the add/ remove buttons from the User if they aren't logged into a Secure Zone you could do so by wrapping your user_favourites Layout within this IF statement: `
`
You can include the user_details Layout like so: <div data-gb-custom-block data-tag="include" data-0='user_details' data-1='my_layout'></div>
Layouts for user_details are stored under the following path: site Manager/code Editor/layouts/modules>module_5/user_details/my_layout.liquid
Next within the "user_details" Layout, you can use the following Liquid variables:
favourite_items
- an array of IDs of favourite WebApp and Module Items you can loop over. This is mostly for use in your logic.
favourite_items_string
- a comma-separated String of favourite WebApp and Module Items. This is formatted ready to be passed into an item_ids parameter for filtering WebApp and Module List views. See below.
<div data-gb-custom-block data-tag="-" data-0='webapp' data-1=', id: ' data-2='1' data-3='1' data-4='my_layout'></div>
<div data-gb-custom-block data-tag="-" data-0='ecommerce/products' data-1=', layout: ' data-2='default'></div>
<div data-gb-custom-block data-tag="-" data-0='module' data-1=', id: ' data-2='3' data-3='3' data-4='my_layout'></div>
All Forms allow Users to edit their details in the CRM. This includes all standard fields like "name" and Custom Field Sets.
All Forms allow Users to edit their details in the CRM.
This includes:
Name
Any Custom Field Sets attached to the Form. Use these to store information that you want to keep up to date.
Standard Form Fields are stored against the Case only and are not stored against the CRM record.
This Article will:
Show how to output Custom Field Set Data in the Form
Show how to display any existing data in the Form- so the User understands that they are editing data.
Explain the process Siteglide takes with User data when a Form is submitted
The flowchart diagram below demonstrates an abbreviated summary of what happens when a Form is submitted on Siteglide. Where the diagram mentions Custom Field Sets, the newer CRM Custom Fields feature is applicable as well.
The most important points to draw from this are:
All Forms will create a Case and all fields submitted will be shown in the case
But only the following fields will update the CRM:
Custom Field Sets attached to the Form
CRM Custom Fields
The user's "name" field
The email field (on first submission only) - this is used as a unique identifier in the CRM.
When using Custom Field Sets and CRM custom fields to update the CRM, it doesn't matter whether or not the User already exists in the CRM, or whether or not the User is already logged in.
In summary, to add Custom Field Set fields to a Form, you'll need to:
Create a Custom Field Set (or choose an existing one)
Attach the Custom Field Set to a Form in Admin. You can mix & match different kinds of fields here.
Check that the Liquid for this field is included in the Form Layout
Add your Form to a Page with the chosen Layout
If you use a default Form Layout, then attaching the Custom Field Set to the Form will automatically add the fields to the Layout. If using a Custom Layout, we recommend you copy and paste the code from the default Layout to your custom Layout before editing it.
Here is an example of a Custom Field Set field added to the Layout:
Note the data-cfs
attribute which gives you a clue this is a Custom Field Set Field and will therefore submit to the CRM record.
CRM Custom Fields work in a similar way to Custom Field Sets, but instead of operating as a group of fields, they can be added to the form individually. One advantage they have over Custom Field Sets is that they use slightly less database records in your usage metrics.
See here for a more detailed explanation of creating CRM fields:
In summary:
In CRM, custom fields tab, create each custom field you need
Attach the CRM Fields to a Form in Admin. You can mix & match different kinds of fields here.
Check that the Liquid for these CRM fields is included in the Form Layout
Add your Form to a Page with the chosen Layout
As with Custom Field Sets, the syntax for adding CRM custom fields to your form is automatically added to the Form's default Layout. You may need to run a pull command if you are using Siteglide-CLI to get any new changes to your default Layout. If using a Custom Layout, we recommend you copy and paste the code from the default Layout to your custom Layout before editing it.
Here is an example of a CRM field added to the Layout:
Note the data-crm
attribute which gives you a clue this is a Custom Field Set Field and will therefore submit to the CRM record. The ID in the data-attribute refers to the CRM field's ID in the CRM; it is different from the ID in the name attribute, which refers to the field's ID in the case.
The User must be logged in
It's extremely useful to display the current values in the fields on Page load. This shows the User the data that is already stored and allows them to make a decision about whether the data needs to be changed.
In Order to fetch the existing Custom Field Set data for the current User, they'll need to be logged in. This means they'll need to have already completed a Sign-Up Form to any Secure Zone and set up a password. You may find it helpful to build an onboarding flow with two separate.
To achieve this, you can combine two Siteglide Features by nesting a Siteglide Form inside a User Details Layout.
`
Parameters:
layout
- Choose a Layout from the following folder in Code Editor: layouts/modules/module_5/user_details/
**Step 2) Place the Form inside User Details **The User Details Layout has direct access to Custom Field Set data, but normally the Form does not. In order to achieve this, we place the Form inside the user_details
Layout. Due to Liquid inheritance, the Custom Field Set data will then be available inside the Form.
Output your Form by writing the code for the Form inside this user_details
Layout instead of directly in the Page e.g. <div data-gb-custom-block data-tag="include" data-0='form' data-1='10' data-2='10' data-3='custom' data-4='custom'></div>
**Step 3) Use Liquid to prefill the HTML values **This will allow you to access the existing User data and their related Custom Field Sets within the Form.
In this example, we have a Custom Field Set "Checkout Address" with a "Profile Picture", a Favourite Colour and a Country field:
As the value
attribute in HTML determines the pre-filled value of a field, we can use Liquid to add it. In most cases, there is an <input> element which can be given a value, eg. in the "Favourite Colour" field:
Values can also be added to <select> elements:
File and Image fields are more complex, each has two elements- a type="file"
and a type="hidden"
field. If you wish the File upload to have validation, both the value
attribute and .required
class should be added to the type="hidden"
input. This is because this is the field that actually has a name
attribute and sends to the database.
This adds the value to the field, but for the Profile Picture, I may also want to show a larger preview of the image outside the field. You can use the same Liquid to display the image, using the asset_url
filter to complete the path:
Attributes:
style="background-image: url('{{this.custom_field_sets.cfs_3.properties.cfs_field_3_1 | asset_url}}');"
- This Liquid would allow the existing image to be displayed on Page Load.
You may wish to split your fields into multiple "User Profile" sections where the User can enter a set of fields, save and then move to another section.
To keep the Cases tidy for multiple Forms and be most efficient with Database Usage, you can optionally use:
A single Admin Form
A single Custom Field Set
Multiple Form Layouts, each displaying alternative sub-sets of Fields. (Name and email can be pre-filled using HTML, to prevent asking logged in Users for this information multiple times in the flow.)
This will mean that Cases for each part of the Form will still be collected in the same location in Admin, but you can use the Form Layouts to control which fields are displayed in each view.
All Forms must include the user_id
and email
fields, but if you want to hide these from the sections which are not visible, you can give these type="hidden"
so that they are not seen in the Sections which do not require them. You can auto-fill their values using the steps in the previous section.
You have installed the
We've added the ability for User's to store their favourite Module items within a "favourite_items" array, they'll be able to "add" and "remove" items from the list which will be stored alongside the rest of the CRM data available to that User in .
Now let's look at how we can output all of the User's Favourite items. The favourite_items object is stored within the
.
The "edit email" and "edit password" fields
See here for a more detailed explanation of
The User must already be Signed Up to any
Before we show you the User Details method which uses a low-code approach, we should note that the GraphQL users
query provides a more flexible approach to fetching user data, including fetching details of users who are not logged in. You can learn more about how to use GraphQL queries here:
Step 1) User Details Contain the existing CFS Data To fetch the existing CFS and CRM data for the Current User, you'll need a Layout. `
See to see how to access data from CRM custom fields within the User Details Layout.
data-file-preview="form_field_10_1_file"
- This sets up the element to preview the next image a User uploads to this field. Read more here: .