Skip to main content
Solved

Junk BASIC DATA

  • April 22, 2026
  • 2 replies
  • 13 views

ROYIBRAHIM
Do Gooder (Partner)
Forum|alt.badge.img+4

Hi All,

Unfortunately, I have some junk basic data values, already used, which prevents me from cleaning and deleting.

Can I hide these values in order not to appear in LoV and not to be used anymore?

 

Many Thanks in advance

Abdeslam

 

Best answer by martin.surasky

Hi ​@ROYIBRAHIM

I think the answer here is “IT DEPENDS”. Let me drill down a bit.

Sometimes you can retire or hide “junk” basic data values rather than delete them, and that is usually the safer approach when they are already referenced. SOMETIMES doesn’t mean ALWAYS... not even USUALLY.

The exact mechanism depends on what kind of basic data the values are (Code String values? Custom lookup/Enumeration? Control Types? User-defined basic data in a specific module?). The patterns below are common in IFS:

Preferred options (in order):


1) Inactivate / Block / Obsolete the value (Best if available)

Many IFS basic-data entities have a status-style control such as:

  • Active / Inactive
  • Valid / Invalid
  • Blocked
  • Obsolete

If the value can be marked inactive:

  • It often drops out of LoVs by default (or can be filtered out)
  • Existing records using it remain intact
  • New transactions can no longer use it

This is the cleanest solution.

2) Use validity dates (“Valid To”)

Some code tables support:

  • Valid From
  • Valid To

Set a Valid To in the past (or end-date it going forward).

3) THIS IS ONLY VALID IF YOU HAVE CONTROL ON YOUR FIELD (MAYBE IT IS A  FIELD CREATED AS PART OF A CUSTOMIZATION/CRIM) - Remove it from selection logic / LoV filters

If YOU control the process of Basic Data creation (Custom Entity or Custom Field) you may be able to prevent it from appearing in LoVs by adjusting:

  • Basic data selection rules
  • Custom LOV filters

4) If the first 3 approaches are not feasible you are left with the option to rename junk values so they scream “do not use” (your only safety backstop)

This many times is the only option available and what most people do. Examples:

  • ZZ_DO_NOT_USE_OLD_VALUE
  • OBSOLETE_LEGACY_CODE

This protects against accidental use even if it doesn’t help with hiding it.

 

Do you know precisely what associations prevent your LOV values from being physically removed? Are those related records part of hour transaction history that you don’t want to remove or you simply don’t know how to remove them as well?

 

Thanks

 

2 replies

martin.surasky
Hero (Customer)
Forum|alt.badge.img+10
  • Hero (Customer)
  • Answer
  • April 22, 2026

Hi ​@ROYIBRAHIM

I think the answer here is “IT DEPENDS”. Let me drill down a bit.

Sometimes you can retire or hide “junk” basic data values rather than delete them, and that is usually the safer approach when they are already referenced. SOMETIMES doesn’t mean ALWAYS... not even USUALLY.

The exact mechanism depends on what kind of basic data the values are (Code String values? Custom lookup/Enumeration? Control Types? User-defined basic data in a specific module?). The patterns below are common in IFS:

Preferred options (in order):


1) Inactivate / Block / Obsolete the value (Best if available)

Many IFS basic-data entities have a status-style control such as:

  • Active / Inactive
  • Valid / Invalid
  • Blocked
  • Obsolete

If the value can be marked inactive:

  • It often drops out of LoVs by default (or can be filtered out)
  • Existing records using it remain intact
  • New transactions can no longer use it

This is the cleanest solution.

2) Use validity dates (“Valid To”)

Some code tables support:

  • Valid From
  • Valid To

Set a Valid To in the past (or end-date it going forward).

3) THIS IS ONLY VALID IF YOU HAVE CONTROL ON YOUR FIELD (MAYBE IT IS A  FIELD CREATED AS PART OF A CUSTOMIZATION/CRIM) - Remove it from selection logic / LoV filters

If YOU control the process of Basic Data creation (Custom Entity or Custom Field) you may be able to prevent it from appearing in LoVs by adjusting:

  • Basic data selection rules
  • Custom LOV filters

4) If the first 3 approaches are not feasible you are left with the option to rename junk values so they scream “do not use” (your only safety backstop)

This many times is the only option available and what most people do. Examples:

  • ZZ_DO_NOT_USE_OLD_VALUE
  • OBSOLETE_LEGACY_CODE

This protects against accidental use even if it doesn’t help with hiding it.

 

Do you know precisely what associations prevent your LOV values from being physically removed? Are those related records part of hour transaction history that you don’t want to remove or you simply don’t know how to remove them as well?

 

Thanks

 


ROYIBRAHIM
Do Gooder (Partner)
Forum|alt.badge.img+4
  • Author
  • Do Gooder (Partner)
  • April 22, 2026

Thank you very much for your prompt answer, dear Martin.

I will investigate to see which option is appropriate for us and come back with the workable one.

Many thanks again.

Abdeslam