October 2026 Release Notes: Visit 6.0 Visit 6 marks a landmark evolution in our product, and brings about many changes and benefits. Events created prior to this release will continue to be supported, however when cloning these events or adding new events, these will be in the ‘Visit 6’ format. Please see new sections in Visit online help available from the release, and upcoming Visit Academy content for detailed information on the new features. When cloning a Visit 5 even to a Visit 6 event: Standard shop products are cloned, activities are not Shop group definitions are cloned but not populated Shops become cloned as catalogs A visit 5 event can (on request) be upgraded to a Visit 6 event, however this is not possible once there are orders (test or real) against shop products. The remainder of these release notes relate to Visit 6 only, so events running in non-legacy mode. Visit Create Email Configuration Email settings are moved to the new communication function under the event menu. This allows centralised management of emails associated with forms. Note that when configuring cloned events while the forms, emails and rules do get replicated, it will be necessary to re-associate existing emails with their forms, also including any previously configured rules. Visitor QR Codes For events making use of tickets (with associate scannable ticket codes), tickets are now scannable via the registrant’s regular Visitor QR code. When using access control mode on Check-In, the ordered access and exchange products are implied through the main code. The individual ticket codes can be scanned interchangeably, however the reverse is not true – scanning an individual ticket is limited to that item only, it does not imply any other tickets or overall access offered by the main QR code. Event->Locations Areas can be represented in the schematic within other areas by making use of their new parent area property. Note this hierarchy has no effect on any associated access control logic configured against their gates, so acts only as a visual aid to the actual layout of an event. We’ve introduced the new exchange location type to associate with the exchange shop product type (see below). Shop Products We’ve introduced the access product type, which is used to automatically associate access control functionality with products registrant as ordered. The area or areas the product gives access to is a mandatory property of this shop product type. The new exchange product type can be redeemed onsite for a product or service. This is similar to an access product, but doesn’t have any access validity implications. The exchange location(s) the product can be redeemed at is a mandatory property of this shop product type. The standard shop property has been maintained, but should see increasingly little usage for Visit 6 events. Use the standard product only when there’s no Visit onsite scanning requirements. New Discount Code Implementation Discount codes have been separated as a separate function from registration codes, offering many advanced options for modifying the cost of orders in the basket. You can: Define automatic, single code and code ranges Configure the validity in terms of dates and usage limits Configure as ‘Amount Off’ or ‘Buy X get Y’ types Offer discounts as percentages or fixed amounts. Note the overall value of an order can never be negative Configure source product requirements for the code to apply, and destination products it applies to Shop Basket Validation A new set of functions provides final checks on the basket when placing an order to sure the purchased items match the event’s requirements. For example when using a group registration, you may want to perform a final validation that all group members have been assigned a particular access product. Shop in Visit Forms Visit 6 permits multiple shop page instances in one or more forms, each page displaying one of the available catalogs. You’ll need to select a catalog for each shop page (there is no concept of a ‘default’), however can also be changed using rules, as was possible to in Visit 5. When combined with group registration functionality, the registrant details capture and the shop products may be interspersed throughout the form, supporting shop first or group first functionality, for example. The basket functionality ensures that the registrant distributes their items amongst the registrants within any applied restrictions, prior to advancing to the checkout. In practice this means you can capture details wherever you wish throughout the form form for main and/or group members, and include shop catalog pages wherever you wish. Scan Simulation Rule testing has been replaced by the powerful scan simulation function found under the Onsite menu. Here you can set up multiple test cases to confirm the intended behaviour of the event is configured correctly. In each case you configure whether the expected result is to allow or deny access. Visit will report on where there is a mismatch between the expected result and the actual result. The schematic view also supports scan simulation, however these tests are not persisted. Visit Connect Ordering Paid Staff Badges Visit 6 makes use of the same shop and basket format as registration forms, and can be configured for the purchase of extra team member passes. Define a catalog page in the shop setup, featuring one or more Staff Badge products Set the visitor registration type of the staff badge product to match that defined in your Visit Connect team management settings From Visit Connect settings, enable the shop function and select the catalog page Visit Discover Visitors using Visit Discover may review any existing orders they have placed through the registration form, and order additional products or services directly in this environment using the same shop and basket format. From Event->Visit Discover, select a catalog to display. You may also use rules to change the catalog displayed based on properties of the registrant, the event or system properties such as the current date and time. These therefore function similar to shop rules on a page in a form. Visit Check-In Check-In 6 will be mandatory for onsite delivery of events created in Visit 6, but will also support older legacy events. We recommend upgrading to the latest version of Check-In, in line with normal best practice. Check-In 5.x cannot be used to deliver Visit 6 events. Scan & go has been renamed Badge Collection Access Control mode now ignores any configured activities at the scanning location. For automated validation against shop We’re introducing Activity Control mode, a dedicated function for scanning against locations hosting agenda activity items with associated times. In the case an activity is of sign-up or paid for type, access control is implied by what registrants have ordered. It’s possible to override this with your own exception rules. Release Notes: Visit 5.68 Visit Create In preparation for Visit 6 on 25th October 2026, this release features many backend changes to ensure final readiness. From Visit 6, events will have a significantly different structure, hence we’re introducing a legacy mode so existing events can continue to be supported and accessed as normal through Visit Create. From this release you will see the legacy tag added to all events currently in Visit. New events added (or existing events cloned) until the release of Visit 6 will continue to be considered as legacy. Test / Live Payment Mode Look out for a powerful new implementation of the shop testing function (simulating a transaction using a test payment). All forms are now considered to be in live mode by default. To access the form testing tools, use this icon. This allows Visit Create users to carry out individual payment tests, without globally changing the behaviour of the form. It also helps de-risk putting a form live when in the (now deprecated) test mode. The testing tools are context sensitive; PSP test/live mode is available at any time when using Visit Create, however other functions are only available when using the form editor (such as the debug mode to disable CSS and JavaScript). Codes The term action code has been deprecated. Previously these codes were used to serve a number of different functions including partner association, tracking and custom ticket code values. Moving forwards Visit 6 will introduce registration codes and discount codes. In preparation for this, action codes have been renamed to registration codes. It’s available as the system question Registration Code, and as the associated dynamic field #registration_code#. You may also pass a code to a form via a URL querystring, using the format ?registration-code=xxxxx You’ll see this new terminology used throughout the platform, including service centre and associate import and export templated. For backward compatibility, the term actioncode will still be recognised as a querystring parameter and a dynamic field, so can be used interchangeably with the new terminology; therefore there’s no need to update existing forms or email templates for example. There will be no changes to the naming of the actionCode field in the visitor API endpoint schema. Form Status Overview The forms list in Visit Create has been extended from a list of form names to a tabular view, exposing core information about the form’s properties. This negates the need to open the form editor to check these properties from the form settings. At a glance you can now view: Whether the form is active. This is based on the configured event dates but may be overridden by custom form validity dates. The default registration type associated with the form The deduplication mode in use Whether the form is configured for use for exhibiting team members (staff) or onsite usage (manned) Whether the form has shop, group, verification or embeddable functionality in use Locations Locations are referenced in many areas of event setup (increasingly with the new shop model being introduced in Visit 6) therefore have been moved under the event menu. You will want to define your areas and locations fairly early on in the event setup lifecycle, rather them being a late addition just before going onsite. Areas are used for activity items in the event agenda, and are also used for shop products and their associated event access control. From the location setup section, you can continue to view and manage your area and gate locations. This will also be the home for the new exchange location type to be introduced in Visit 6. New for this release – you can now define the parent area of an area, so you can nest multiple locations inside each other. This is particularly beneficial when using the new schematic view. Use this button to switch between a tabular and a schematic view. The schematic view shows the relations between your gates (displayed as arrows) and areas (displayed as coloured zones). You can change the colour of any area by changing the RGB value defined in its properties. Visit Check-In There is no associated version 5.68 with this release. Please continue to use the existing latest 5.67 version. Please note during this transitional phase to Visit 6 with its new shop, it will unfortunately not be possible to support onsite payments through Visit Check-In due to technical restirctions.
