We deployed a custom business rule last week to display an additional benefits field on employee profiles during open enrollment. The field definition was created in the Benefits Admin module and linked to our custom benefit plan object. However, employees are reporting they cannot see this field when accessing their profiles, even though the business rule shows as active in the system.
The custom field is defined as a picklist with three values (Standard, Enhanced, Premium) and should appear in the Benefits section. We’ve verified the business rule trigger is set to fire on profile load, but something seems to be blocking visibility. The field appears correctly in our test environment but not in production. Has anyone encountered similar issues with custom benefit fields and business rule assignments?
Based on your description, this is a multi-layered configuration issue involving all three critical components: custom field object definition, business rule trigger assignment, and role-based permission mapping.
Here’s the complete resolution approach:
1. Custom Field Object Definition:
Navigate to Admin Center > Configure Object Definitions > Benefit Plan object. Locate your custom picklist field and verify these properties:
- Field Status: Active
- Visible on UI: Checked
- Show on Employee Profile: Enabled
- Required for Open Enrollment: Set according to your business needs
If any of these are incorrect, update them and save. The field must be properly defined at the object level before any other configuration will work.
2. Business Rule Trigger Assignment:
Go to Admin Center > Manage Business Rules and open your custom rule. Verify:
- Trigger Event: Set to ‘onInit’ (fires when profile loads)
- Execution Context: Employee Self-Service
- Target Field: Your custom benefit field
- Condition Logic: Should evaluate to true for all employees during open enrollment period
Test the rule logic using the built-in rule tester with sample employee data. If the rule doesn’t evaluate to true, your field won’t display regardless of permissions.
3. Role-Based Permission Mapping:
This is likely your primary issue. Navigate to Admin Center > Manage Permission Roles > Employee role:
- Locate the Benefits Plan object in the permission list
- Expand to show field-level permissions
- Explicitly add your custom field with ‘Read’ permission
- If the field should be editable during open enrollment, also add ‘Write’ permission
- Save the role and propagate changes
Critical Step - Permission Propagation:
After updating permissions, you must trigger a permission refresh:
- Go to Provisioning > Company Settings
- Select ‘Refresh Metadata’
- Wait 10-15 minutes for the cache to clear
- Have a test employee log out completely and log back in
Verification Process:
After completing all three steps, test with a non-admin account:
- Log in as a regular employee
- Navigate to Benefits section on profile
- Verify the custom field appears with the correct picklist values
- Test that the business rule properly controls visibility during and outside open enrollment periods
The key insight here is that all three components must be correctly configured and aligned. Your business rule can be perfect, but without explicit field-level permissions in the Employee role, the field remains invisible. Similarly, permissions alone won’t help if the field object definition doesn’t have UI visibility enabled. This is a common configuration gap in SuccessFactors Benefits Admin customizations, especially when moving configurations from test to production environments where permission roles may have different settings.
I’ve seen this before. Usually it’s a role-based permission issue. Check if the employee role has read access to your custom field object. Go to Admin Center > Manage Permission Roles and verify that the Employee role includes the custom field in its permissions. Even with a working business rule, if the role doesn’t have field-level access, it won’t display.
Just to add - if you recently deployed this, make sure to clear the platform cache. Sometimes field visibility changes don’t take effect immediately due to cached metadata. You can do this through Provisioning > Company Settings > Refresh Metadata, or wait for the automatic cache refresh cycle.
Another thing to verify is your business rule trigger assignment. Make sure it’s assigned to the correct event - should be ‘onInit’ for profile load scenarios. I’ve seen cases where the trigger was set to ‘onChange’ which only fires when a field value changes, not on initial page load. Check your rule definition in Manage Business Rules and confirm the trigger type matches your requirement for displaying fields during open enrollment.
Also worth checking your field definition itself. In the Benefits Admin configuration, make sure the ‘Visible on Employee Profile’ checkbox is enabled for your custom field. Sometimes the field gets created with backend visibility only, which means admins can see it but employees cannot. Navigate to Configure Object Definitions > Benefit Plan and review the field properties. The visibility flag must be set at the object level before any business rule can expose it to users.
Thanks for the suggestions. I checked the permission roles and the Employee role does have read access to the Benefits Plan object. However, I’m not seeing the custom field explicitly listed in the field-level permissions. Do I need to add it separately, or should it inherit from the parent object permissions?
You need to add it explicitly. Custom fields don’t automatically inherit permissions from the parent object in SuccessFactors. Go to the specific permission role, find the Benefits Plan object section, and manually add your custom field with read permissions. This is a common gotcha - the business rule can be perfect, but without explicit field permissions, users won’t see anything.