Objective
After reading this article, you will understand how to set up Mobile Cards on the Youreka Mobile App.
Mobile Cards is a feature that allows an admin to change the primary display on the Youreka Mobile App. In earlier versions of Youreka, the primary display on the mobile app included a list of forms that had been made available to users (see the left side of the screenshot below). This would allow a user to select from any of the forms in the list, and immediately be able to edit those forms.
With the Mobile Cards feature, admins have the ability to display an alternate record to users on the primary display (see right side of the screenshot below). This is significant because if an organization tends to manage their business processes around Accounts, Cases, Work Orders, or Tickets as opposed to Forms, Mobile Cards can be used to improve the user experience. When Mobile Cards are enabled, end users can tap on a card, and reveal a list of Forms related to that record.
From the mobile card view, users have many things they can do. They can click on the card, which navigates them to a list of forms for that record. They can expand the mobile card, to view more information about the record. They can click on the map icon on the card (if distance tracking is enabled). They can also use the search bar at the top of the menu, to filter down the cards that are displayed.
Configuring mobile cards requires an admin to use the settings in the Mobile Admin tab. Use the screenshot below, as well as the corresponding bullet points to understand what each component on the Mobile Admin tab does.
- Enable Mobile Cards - Enables or disables mobile cards. When this setting is turned on, object-specific mobile cards will be enabled for all Youreka Mobile users. When this setting is turned off, the original Youreka mobile experience will be available to end users, where each card on the application represents an individual Form record.
- Primary Object - Allows you to define which object the mobile app will show for end users. The screenshots above show different mobile experiences where the Primary Object is set to Account, Contact, or Ticket, just as an example.
- Summary Field Set - This selector allows you to define which fields are shown to end users on the Mobile Cards. Create a field set on the Primary Object, and drag and drop desired fields onto the field set to have them appear on the mobile app. The first 2 fields in the field set will be displayed on the compact view of the mobile card. The rest of the fields in the field set can be shown by clicking on the expand button on the mobile card. It is also important to understand that the fields in the field set are important for the purposes of using the filter list search functionality on the Youreka Mobile App. Users can type in in the Filter List search bar at the top of the mobile card view, and any information that exists in the field set will be used to filter down the cards that are displayed.
- Form Sort Order - Defines the order in which Form records will display to the end user after they tap on a mobile card. Remember, when Mobile Cards are enabled, users can tap on a card, and see all of the forms associated with that card's record. This setting defines the order in which those records are displayed.
- Object Filter - allows the admin to define which records will be shown on the mobile app.
- You can write a filter in a SOQL where clause that informs the mobile app which records to display for the end user. Any fields used in the expression should be from the Primary Object and you should be using API Field Names as opposed to Field Labels.
- For complex queries, consider using a boolean formula field on the primary object, and filtering based on the value of just that field. A few examples of Mobile Card filters can be seen below. All of these examples assume that the end user is using Account mobile cards, but the concept holds true with any object.
- Consider your filters carefully. Ensure they are appropriate for showing your end users the information they need (no more, and no less). Also consider how your filters relate to the information your end users are manipulating in your Youreka forms. For example, if you filter Account Cards so that users can only see Accounts of type "Prospect", and in one of your forms, the end user changes an Account from "Prospect" to "Customer", the mobile card will disappear upon sync. Carefully consider the way your filters are constructed, and ensure they provide the sound end user experience without revealing or hiding information unintentionally.
Object Filter Examples
Object Filter Example | Description |
---|---|
Type = 'Prospect' |
This filter is used on the Account object, and retrieves all Accounts that the end user has access to, and where the Type field = 'Prospect'. |
ID NOT IN (Select AccountId from Contact) |
This filter is used on the Account object, and retrieves all Accounts that the end user has access to, and where the number of Contacts is greater than 0. This filter is interesting because it utilizes a nested query - which can be very powerful. |
Account_Owner_Is_Current_User__c = TRUE |
This filter is used on the Account object, and retrieves all Accounts that the end user has access to, and where a custom formula field on the Account = TRUE. In this situation, we may have a custom checkbox formula field on the Account that determines if the current user equals the owner. Consider creating formulas on the objects you intend to filter to help assist with your filter statements. |
(Status = 'Dispatched' OR AND SchedStartTime = TODAY AND Id IN (SELECT ServiceAppointmentId from AssignedResource WHERE Service_Resource_User_ID_Current_User__c = TRUE) |
This filter is used on the ServiceAppointment object (FSL). It's observing the standard Status and Scheduled Start fields to ensure that only today's ServiceAppointments are displayed.
It is also utilizing a nested query alongside a custom formula field* on the AssignedResource object to ensure that only the assigned resource is the individual who would see this card. This aspect of the filter is especially important if your OWD for Service Appointments is set to Public and/or your field techs have Read All permissions on the SA object. |
Comments
0 comments
Please sign in to leave a comment.