Conditionally Disabling Descriptive FlexField (DFF) Segments in E-Business Suite

There have been quite a few posts on the Oracle OTN Forums E-Business Suite space recently with people asking some kind of variation of the following question. How can I disable specific descriptive flexfield segments for specific users? As per My Oracle Support Document 372034.1, this functionality is not supported by forms personalization and there is an enhancement request in place to achieve this, however at time of writing this is not supported. So instead I am going to present a method of achieving this using functional setup within the application – Flex Value Security. As this approach uses value set security then it of course follows that the method only works for those flexfields segments having a value set defined against them (of a type that security can be enabled)! That might seem a bit of a restriction at first, and whilst I suppose it is, I would say in general that most descriptive flexfield segments I see across different sites either independent sets assigned to them (or if they haven’t then they should have!). The descriptive flexfield I will be using for demonstration purposes is configured as follows.

---

  So let’s take our trivial example. I want to set the Testing 2 segment to be disabled for any users who don’t have the JK Demo responsibility. So first we take the value set XXJKTEST2 and we enable security. We must also enable security against that segment in the flexfield definition. Now we define a security rule against the above value set which excludes all values in the set. Note however that you must have at least one include rule. Note that this is a numeric value set, so hence the range runs from 0 to 9999. This works exactly the same with character based sets, you just exclude the character range instead. Finally we assign the security rule to our custom responsibility. So now when I go into the form my LOV has no entries. If I attempt to type in the value manually then I see the message we defined earlier. The most obvious thing here however is that the flexfield still appears as enabled. So as you can see it’s not an ideal solution on the grounds that it doesn’t really make it read-only – it just prevents the user from being able to enter anything in there. Which I guess is as good as being disabled, it’s just a bit more confusing. The other option that I have seen in use (and I’m not advocating it) is to use a forms personalization that does pretty much this…

1. WHEN-VALIDATE-ITEM
2. Read the value off the database
3. Check whether the value read differs from the value in the field
4. If a difference is found then raise an error

…which does work, however again you don’t get a field which renders as disabled, and it’s likely your instance has personalizations locked down to developer/sysadmin users whereas value set security can be opened up to a more functional level of user. It also works for fields which don’t have value sets assigned to them. However; I would suggest that if you can use the method described here instead of a personalization then do so.