Variants

Some objects might use the same lime type, but be still different in some way. For example, the same company card is used for both prospects, customers and suppliers. The differences can make you want to show these different types of fields, tabs and other components in different ways.

Variants help you visualize the same object in different ways, based on the value of a specific field.

Typical scenarios where variants are useful:

• A support ticket of type "power outage" should hold information related to area, known power outages and such. Whereas a ticket of type "invoice question" should hold information related to previous and open invoices.
• Deals of type “solar panels”, “electricity”, “grid”, “broadband”, etc. have a lot of non-common fields. Displaying all fields on the object card will confuse the end users and make it harder for them to understand what’s important and not.
• You may want to make all fields on a closed ticket read-only, so that users do not change them accidentally.
• A "small deal" might only have five fields to fill out. A "big deal" might have 20 fields to fill out.
• Displaying a tab called “Business opportunities” only may makes sense, if the “Company” is our “Customer” not “Supplier”.

Info

A record's Variant should in most cases not change over time. For example: a broadband ticket will (almost) always be a broadband ticket, a supplier will (almost) always be a supplier and a send-out will (almost) always be a send-out. It is therefore not recommended to use Variants for things such as Deal Status or Ticket Status since those properties change over time. This can lead to undesirable behaviors where fields and tabs appear and disappear, or become read-only or required, while the user interacts with the card. The constantly changing layout can create confusing user experiences. These kinds of solutions also tend to be hard to maintain. Please consider other designs solutions for catering for the user's different needs for a record's different statuses.

How to enable variants for a lime type

To enable variants for an object, navigate to Lime Admin > Views, and then click on the object of your choice. Then find the section called “Variant Field”. Pick the field which will be the decisive field of your variants.

Info

If you cannot see the variant section, it is because object variants can only be based on a few types of fields. At the time of writing this guide, we only support Option fields, and Relation fields. Therefore, if such fields does not exist on the object, the “Variant Field” section will not be displayed in the Admin page.

Once the field is chosen, press SAVE; and now you should be able to see a new sub-menu called Variants, under the object’s name in the Views menu.

How to configure variants

Expand the Variants sub-menu, and press the plus button to add a new Variant for that object.

Next step is to give your variant a proper name.

Info

1. Keep in mind that end-users will see the name that you write here. Currently, this name is displayed on the object card’s header area, as a supplementary information on the sub-heading, after the lime type’s name.
2. It is possible to add a translation key here too, for multi-lingual setups. Read more in Localization.

Below the name field you will see a dropdown list, which allows you to select one or multiple items from the Variant field that you have chosen at the first step.

Let’s say you have chosen “Buying status” as the variant field before. Now you can select one of the statuses to base your variant on; for instance “Active”.

Once you save this setting, you will notice a new node called “Card” gets added under the variant.

Info

Please note that it is possible to choose multiple items to activate the same variant.

It is now possible to configure how the card should be displayed to the end-users, when the Status is set to Active.

By clicking on the Card you will notice that an exact copy of the existing card configuration is present here as well. We call that the “Default variant’s card config”, and it is there to make it easier for you to add new fields or sections for your new variant.

Every time you add a new fresh variant, we duplicate the default card config and use it as a base for your newly added variant.

Info

Please note that you can even hide or show tabs (relations), or web components for each variant individually.

Best practices of configuring cards for different variants

The variants is a feature that is intended to make life easier for the end-users of the CRM. The core idea is that you don’t want to show things that are “irrelevant” to the end-users, to reduce their brain work, and help them focus on processing things that are needed. However, bad configurations can easily confuse the users even more.

Place the variant field first, or in the top section

Since changing the value of the variant field defines the content and layout of the object card, it is crucial to place the variant field somewhere at the beginning, or in the top section of the object card.

This way, when end-users change the variant field, changes happen visually below the field, making it easier for user to continue filling in the form in a natural flow of reading, from top left, to bottom right of the screen.

Keep the variant field in the same place for all variants

When users change the value of the variant field, it is important that the field doesn’t change its place in the layout, as the card variant changes. Users may have simply clicked on the wrong choice. If the variant field moves around, it will make them confused and force them to look for it and find it in the “new” layout.

Warning

Please note that changes for the end-users happen in real-time, without any delay or animations. They don’t have to press the Save button for instance, for the card to get the new variant layout.

Try to show, not hide!

It is not easy for the users to notice when fields or sections disappear from the screen. Such a thing usually creates questions for the user. They will wonder, “Wait, what happened?” or “Oh, what was there? Why did it disappear? Did I do something wrong?”

Additionally, users may type things in those fields which disappear as soon as the system switches the variant.

It is strongly recommended that your default card variant has as few fields as possible. This way, as soon as the value of the variant field is changed by the end-user, you actually show more fields or sections that are related to the new variant.

So, keep few things in the default card, and add more when the variant gets relevant.

Cards and Add New Dialogues

The default config of an object card is displayed in the add-new dialogue as well. Also, if users change the variant field while creating a new object, the layout of the card will also change in front of them. Keep this in mind when designing the card variants.

However, you have some additional features to incorporate, which are available both on fields and on sections of the card. You can choose to show an entire section or field, exclusively on the overview tab, or on the Add New dialogue.

For example, a section that includes readonly fields which are fetched from a 3rd-party integration doesn’t make sense to display when the object is being manually added by the user.

This configuration can of course be done independently for each variant. However, it most probably makes sense to think about it and define this in your default config, so that it gets automatically applied to all the other variants.