Idea ID: 2825645

Increase the SMAX Data Domain Limit to Over 5000

Status : Waiting for Votes
Waiting for Votes
See status update history
9 months ago

As of SMAX 2020.08 the domain limit is 1000 records. We’d like to use data domain segmentation to prevent users from seeing records for other customers (specifically users from other customers) but we have over 5,000 customer records which far exceeds the current limit of 1000.

This idea was originally in Idea ID 2815792 "Increase the SMAX Data Domain Limit" and was marked as delivered since the limit was increased from 250 to 1000 in SMAX 2020.08 but it is not sufficient for the use case I'm trying to address. To address my use case the limit would need to be at least 6000 (aka over 5000).


  • Thank you for sharing your idea! It’s open for comments and kudos, and we’re looking forward to input from the community. Once there is enough community traction, it will be further reviewed by the product team.

  • I believe the entire Data Domain concept should have been implemented as a separate entity (data table), and using MANY2MANY links between records and data domains instead of the very special ENUM_SET field type.

    A separate data table would have avoided many limitations that do currently exist:

    • A limit on the number of possible data domains. Enumeration lists will always in size. 250 entries seemed fine in the beginning, then 1000 was set as the new limit with the feeling that now it should be definitely enough. Next milestone would then be 6000, but I can already predict that this will also be considered insufficient at some point in time.
      With a separate entity, there would be no such limit.
    • Records in a separate entity table can be easily managed (created, deleted, imported or exported)
    • There is a readily available method to link multiple such entities to a ticket (MANY2MANY associations).

    Maybe such an alternative implementation of data domains would have come with a performance hit. But at the DB level, both implementations would result in very much the same time of join query, so performance could very well be similar.

  • In your case, I think 5000 is not also sufficient as we have an expanding client over a year.

    Best if they can just remove the limit or apply another system condition like make it visible based on user company.