Got it, let's figure out how to mask that sensitive field for specific user groups in Oracle EBS R12—this is a common privacy requirement, and I’ve walked through a few reliable ways to make it work:

This is the most straightforward low-code approach, perfect if you don’t want to mess with underlying forms or code directly. Here’s how to set it up:

• Open the target form, then navigate to Help > Diagnostics > Custom Code > Personalize to launch the personalization tool.
• Create a new rule with these key settings:
  • Level: Pick Form if you want the rule to apply across the entire form, or Item if you only need it for this specific field.
  • Event: Choose POST-QUERY (ideal for masking fields when data loads into a list) or WHEN-NEW-ITEM-INSTANCE (triggers when the user clicks into the field).
  • Condition: Add a SQL check to verify if the current user is in your restricted group. For example, using the group name:

    EXISTS (
      SELECT 1 
      FROM FND_USER_GROUPS FUG, FND_GROUPS FG 
      WHERE FUG.GROUP_ID = FG.GROUP_ID 
        AND FG.GROUP_NAME = 'YOUR_RESTRICTED_GROUP' 
        AND FUG.USER_ID = FND_PROFILE.VALUE('USER_ID')
    )
    

  • Action Type: Select Set Item Value.
  • Action: Set the item’s value to '######' (make sure you match the item’s data type—if it’s a number field, you might need to adjust, but string masks work for most text-based sensitive fields).
  • Double-check the Context settings to ensure the rule only activates for your target user group, then enable the rule.

If Form Personalization isn’t flexible enough (say, you need to keep the actual field value intact but only mask the display), you’ll need to tweak the form’s code:

• Open the form’s .fmb file in Oracle Forms Builder (you’ll need EBS development privileges for this).
• Add logic to either the POST-QUERY trigger (for list views) or WHEN-NEW-ITEM-INSTANCE trigger (for individual fields):

  DECLARE
    l_is_restricted_user BOOLEAN := FALSE;
  BEGIN
    -- Check if current user is in the restricted group
    SELECT CASE 
             WHEN EXISTS (
               SELECT 1 
               FROM FND_USER_GROUPS FUG, FND_GROUPS FG 
               WHERE FUG.GROUP_ID = FG.GROUP_ID 
                 AND FG.GROUP_NAME = 'RESTRICTED_GROUP' 
                 AND FUG.USER_ID = FND_GLOBAL.USER_ID
             ) THEN TRUE 
             ELSE FALSE 
           END 
    INTO l_is_restricted_user 
    FROM DUAL;
  
    -- Mask the field if user is restricted
    IF l_is_restricted_user THEN
      :YOUR_BLOCK.YOUR_ITEM := '######';
    END IF;
  END;
  

• Compile the form, generate the .fmx file, and upload it to your EBS server (always back up the original form first!) to avoid breaking existing functionality.

If your form pulls data from a custom view instead of a base table, you can handle masking directly in the view logic:

• Create or modify a view to conditionally mask the sensitive column:

  CREATE OR REPLACE VIEW CUSTOM_SENSITIVE_VIEW AS
  SELECT 
    col1, col2, -- other non-sensitive columns
    CASE 
      WHEN EXISTS (
        SELECT 1 
        FROM FND_USER_GROUPS FUG, FND_GROUPS FG 
        WHERE FUG.GROUP_ID = FG.GROUP_ID 
          AND FG.GROUP_NAME = 'RESTRICTED_GROUP' 
          AND FUG.USER_ID = FND_GLOBAL.USER_ID
      ) THEN '######' 
      ELSE sensitive_column 
    END AS sensitive_column
  FROM base_table;
  

• Update your form’s data source to use this view. Now, restricted users will see ###### for the sensitive field, while others see the actual value.

• Test thoroughly: Validate with two users—one in the restricted group and one outside—to ensure your rule works as intended and doesn’t affect unintended users.
• Follow EBS best practices: If modifying forms, use a custom TOP directory instead of overwriting standard Oracle forms (this prevents your changes from being wiped during EBS upgrades).
• Check data types: If your sensitive field is a number or date, adjust the mask to match (e.g., use 999999 for numbers) to avoid validation errors.

内容的提问来源于stack exchange，提问作者Francesco Baldacchini