Design Patterns : Creating Instances of an Entity

A chance conversation this week brought up another design pattern that is quite common. The request is a simple one – I want to ask the user in an interview to create some instances of an entity.

There are essentially several options – using both the standard Entity Collect control or an Entity Container. It all depends on the desired effect and the level of control you want to give the user.

Option 1 – Basics

Use a fixed value or a dynamic attribute value to control how many Instances of an Entity are presented to the end user. Consider the following. I want my interview user to record lost luggage. I want users to be able to specify how many luggage items they want to record, and then do it either in a Table ( single Screen) or Form (one Screen per Luggage item).

Upside : it’s completely standard and requires nothing other than an entity and some attributes. The first Screen collects the number of items, and the second Screen (if using a Table) collects the luggage items as Instances of an Entity.

Screen 1 – Collect the number of items of luggage
Instances of an Entity - Standard Feature
Screen Two – display the required number of dynamic blank instances.
Runtime – I entered 2 as my quantity and the initial display shows 2 items of luggage. But I can delete them and enter 100 if I want. I can of course remove the Add and Remove buttons but that is just “on or off” and it applies to both. If I remove the Add button I remove the Remove button as well.
Design Time : remove the Add/Remove buttons

Downside : the user can add and remove as many Instances of an Entity as they want. The property controls the initial display of blank instances, but does not stop the user from either deleting or adding as many as they see fit. So the level of control is low. As we just mentioned there are some solutions to remove features such as the buttons but it’s not as flexible as we would maybe need.

But this is all good, still, since there is no code and no configuration beyond simple control properties. Where the “other option” comes in is usually in a highly controlled situation with some requirements for the Instances of an Entity:

  1. The luggage must have a numeric identifier like 1,2,3,4 and the user must not be able to change that.
  2. The user can only create a specific number of luggage items, with upper and / or lower bounds

At this point, you can look to option two:

Option 2 : Still No Code – Use an inferred Entity and an Entity Container

Again this is no code – there is absolutely no need to use any JavaScript to do anything (although you might restyle the container but that doesn’t affect the outcome). You can, as in the first example, use either a Form-based (one luggage item per Screen) or a table-based (all items on one Screen) approach. This makes no difference to the outcome either.

Screen 1 – An Entity Container

This time around to save space the number of luggage items is collected on the same Screen. It does not have to be. Notice that there are two areas for entering the number of luggage items.

Screen 1 – Visibility rule on the manual entry

What I don’t want to do is have to provide a drop-down with every imaginable number in it, just in case the user wants to create, say, 8 items. So I create Value List for the initial dropdown and a second, numeric entry, for larger numbers.

Larger Numbers between 5 and 10 only – as an example

For the end user we make it obvious by including a different display text in the dropdown once we reach the larger numbers.

Instances of an Entity - Setting up Dropdown
Value List with Different Label for larger volumes

The actual luggage is created using a loop. Now, loops can be bad if they are not controlled and not managed properly, but here the risk is very small given how much we control the value of the number of luggage items.

Rules for luggage item instantiation and other things

To save space I have put all the rules together so you see visibility and inference rules in one place – not good practice but it keeps the number of screenshots to a minimum. You can see we infer the first luggage item if there is at least one, and the others are inferred if the number is larger. In total therefore we have two reference relationships added to the model.

The end result is rather pleasing – the luggage items are directly identified by their numeric indicator and the user can add all the details.

Instances of an Entity - Setting up Entity
The identifying attribute is a number

The end result looks a little like this demonstration. The project can be found here in the Online Shop.

For more about relationships and entity inference, see our series about Relationships (13456, 789). There are also some good examples in the Online Documentation of the Example Projects. Of course the example shown can be further tweaked and enhanced, even can have code added (but only with a good reason to want to customize the behaviour or display of the Entity Container for example).


Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Intelligent Advisor IT Consulting Serving Customers Worldwide
Hide picture