Who is this article for?

Users who want to perform a search in the Classic UI

Reporting authorities, roles, and record access controls restrict data visibility.

As you are preparing to deploy a new business process or update an existing one, carefully consider the custom configuration requests.  Don't over-complicate the business process. Just because an application can be tailored to meet a request doesn’t mean it should.  

Consider the following:

• is the process confusing to the end-users
• does it require additional training for end-users
• is it going to be labor intensive and expensive to maintain
• will it require additional testing after each change
• will it make company-wide reporting more difficult

Tips

• Take advantage of the summary card to display essential information needed by the current assignee to make their decision.
• Avoid page scrolling or navigating to another tab for information by using the collapsible regions in the record details card or Model Templates to quickly collect child level data. 
• When changes are required, consider using a Request Checklist (download .pdf) and reviewing the Understanding writing requirements article. The checklist contains many questions that Admins need to consider when submitting a request. Be as thorough as possible and include any other information necessary to ensure accuracy of the change requirements.
• Whenever possible, use single-sign-on (SSO), allowing users to log in without requiring a username and password.
• Consider the need for small screen object views.

Branding guidelines

The user interface (UI) adheres to established branding guidelines aimed at optimizing user experience and are specified within the Platform, which is consistent across all customer environments, including standardized colors, fonts, font sizes, and other UI elements. 

A key advantage of standardizing the user interface is that it ensures both new and existing users can rely on the consistent placement of visual navigational elements, such as the Homepage button, dashboard layouts, and the standard workflow layout for objects. Each of these platform components contains customizable application content and behaviors, which are detailed below.

Common fields

Verify that Common Fields can be searched and reported on across multiple modules. There are three types of common fields:

• Global
• System
• Custom
  • Checkbox
  • Date
  • Numeric
  • Text (including picklists, references to other objects, Persons, and Teams)

Admin dashboards

Admin dashboards provide a wonderful way for admins to share information. These dashboards provide users with a consistent and way of accessing:

• Common reports
• Shortcuts to create new records
• Shortcuts to view assignments
• Custom dashboard components
• Custom object instructions
• ...and more

Notifications

It is important to verify system and module notifications. There are four distinct types of notifications, each serving a specific purpose and offering unique configuration options:

• Default Notifications
• Module Notifications
• Report Notifications
• Custom SSRS Reports & Charts Notifications

For information on each of the notification types and custom configuration options, see Understanding notification types.

Help tools

Confirm embedded help provides users with information where it is required. Instead of needing to exit the application to access a separate help library, users receive guidance directly within the app, thereby enhancing the user experience and facilitating the completion of tasks more efficiently.

Luminate Documentation Library 
The Luminate documentation library provides Platform related documentation and can be accessed through a user's profile menu under Help. The Luminate articles do not represent customer specific applications.

Knowing the importance of providing help to users, in-line help is available to improve user specific application needs. In-line application help documentation is typically configured during the initial project phase, but it is ultimately up to the customer. Once the project has been deployed, customers can update the in-line application specific documentation through support tickets.

Help options

• Button Labels - Button labels can be configured to convey to the user exactly what will occur when they click the button.

• On-Screen Instructions - Detailed instructions can be included on the screen. This can include workflow instructions as well as inline instruction boxes to further guide the user.

  

• Empty-Value Text - If a field is empty, it can be configured to display some brief instructions (up to 250 characters) in a light gray text. Once any character is entered these instructions are removed.

  

• Hover Help - Any field can have hover help enabled. When the user hovers over the field, a question mark icon with instructional text is displayed.

Here is an example of help options for Button Labels, On-Screen Instructions, Empty-Value Text, and Hover Help.

* Many of these help options can be authored, configured, and maintained by Module Developers if they have taken the required training courses and their organization has a Gold or Platinum support plan.

Mobile application deployment

Recommend Client Configuration
Refer to the Recommended Client Configuration for details about supported OS versions, minimum hardware requirements, and other considerations.

• The mobile app supports all three major platforms (iOS, Android, and Windows), we recommend iOS devices, and specifically iPads to deploy long or complex forms. iOS provides the best overall experience, and Android and Windows may not yet have support for specific features. Those platforms should be evaluated on an as-needed basis.
• If devices use shared logins, users must log off from their devise before giving it to another user to keep the two users' data properly segmented.
• A Mobile Device Management (MDM) should be in place to ensure devices are password-protected and encrypted.
• The latest versions of the iOS and Android apps can be downloaded from the Apple AppStore and Google Play Store, respectively. The latest version of the Windows app is available directly from the system upon request.
• Mobile forms, procedures, and observations work well on a phone-size form factor, but certain functionality, like annotating PDFs, work best on larger (tablet) form factors. Mobile Work Packages specifically require a tablet to render because of the larger screen size requirements.
• When a per-app VPN is used, please work with a Technical Account Manager (TAM) or Project Manager (PM) to check setup/configuration requirements before finalizing a mobile security stack.
• To make it easier for users to connect to their specific area, distribute cards or emails with QR codes, or train the users how to scan the QR code from the desktop browser.

Mobile FAQ

• Can a device be used without Wi-Fi? Yes, the mobile app allows users to complete work without Wi-Fi or network connectivity. When the mobile app is online again, any forms submitted while offline will be synchronized automatically. There are some features, such as search and ad hoc categories, which require network connectivity.
• How often is the app updated? All updates are managed through a set release schedule. iOS or Android devices are set up to take updates automatically, no action is needed. The Windows app provides updates via SFTP and can be distributed to users through an MDM.
• Does the mobile app work with a VPN? The app works with standalone VPNs like AnyConnect or GlobalProtect. For added support for per-app VPNs iOS, including for certificate-based VPNs, please contact a TAM to further discuss compatibility options.
• Can I require users to reauthenticate if they are inactive for a certain amount of time? Yes, an option that requires users to reauthenticate on the admin screens is available. There is a setting called 'Oauth Timeout' on the preferences screen that an administrator can update accordingly.
• How do users authenticate? Users authenticate using a username and password, or with their company username and password over SAML 2 Single SignOn. Once a user is authenticated, the mobile app uses an OAuth token to log the user into the app automatically until they explicitly sign off or the token expires. The default for the token expiration is set to one year, but we recommend the expiration period to align with company security policies using the 'Oauth Timeout' on the preferences screen.
• Can mobile users submit anonymously? Some modules can be submitted anonymously. But careful consideration should be taken to identify when mobile forms, observations, and other items should or could be anonymously submitted.
• Can an .MSI installer be provided for the Windows Mobile App? No, we do not support installing via the .MSI installer. The Windows Mobile app is a UWP app with its own installation script. The latest version of the app is available upon request.

Summary of key mobile features

Data visibility and access control

Each customer has the authority to determine the way access to data is regulated. Should the application data be accessible to all users, thereby allowing everyone to view and potentially benefit from it? Alternatively, should access to the data be restricted, limiting visibility to a predetermined group of users?

There are three methods available for controlling access, each possessing its own unique capabilities. These types of access control may be employed individually or in combination, as necessary, to achieve the desired access control outcomes. The links below provide more detailed descriptions of each option.

• Roles
• Reporting Authorities
• Record Access Control Rules

Deployment and application ownership

While Ideagen oversees the computing environment and all supporting applications, it is the customer who retains ownership of the application. Consequently, it is the customer, and a designated individual, who bears responsibility for the overall design and functionality of the application.

This design oversight includes:

• Fields, including prompt names, rules, behaviors, and properties
• Region placement
• Workflow
• Business logic (for example, if this field is checked then skip this workflow task)
• Print requirements

Understanding what is possible is a key first step in owning an application. The Writing Requirements page provides valuable information to help admins understand what is possible with their applications.

Application owners are also often called a Support Admin. Admins are responsible for providing first-level support to end-users. As needed, admins will also be responsible for submitting a ticket for incidents and change requests.

Testing changes

An important duty of any admin is ensuring the application meets the requirements of the business. To validate that these requirements are being met it is necessary to perform various quality assurance tests for each application.

These tests are needed during the initial project, prior to go-live, and after the application has been modified when an incident is found or changed is needed. Testing should always be performed against a defined test-script that provides a step-by-step flow detailing how the application should behave.

If a test fails, this failure needs to be documented in a ticket. The test script steps and comments will provide thorough notes for a TAM, PM, or Module Developer to review as they make the requested adjustments.

If a test is successful, but the results are not what the business needs, the requirement and test script documents should be reviewed to identify the gap. Once the gap has been identified, a review of the project scope will be conducted.

Additional resources to download