Skip to content

System Data

System data includes tables that configure security (users, permissions etc.) and scheduling system-wide settings.

See the Scheduling System Schema Guide for more detail in the latest IFS Planning and Scheduling Optimization (PSO) documentation.

Tables & Rules Mapped

Table Rule
Entry Entry
External_Task_Parameter ExternalTaskParameter
Groups Groups
List List
Org_Validation_Value OrgValidationValue
Organisation_Permission OrganisationPermission
Polygon Polygon
Polyline Polyline
Profile Profile
System_Data_Update SystemDataUpdate
Terminology_Organisation Terminology_Organisation
Travel_Time_Profile TravelTimeProfile
Group_List GroupList
Group_Permission GroupPermission
List_Entry ListEntry
Org_Schedule_Exception_Type OrgScheduleExceptType
Organisation_List OrganisationList
Polyline_Point PolylinePoint
Profile_Parameter ProfileParameter
Travel_Time_Barrier TravelTimeBarrier
Travel_Time_Weighting TravelTimeWeighting
Users Users
Well_Known_Area WellKnownArea
Travel_Time_Barrier_Blockage TravelTimeBarrierBlock
Travel_Time_Polygon TravelTimePolygon
User_External_Task UserExternalTask
User_Group UserGroup
User_Custom_List UserCustomList
User_List UserList
User_Parameter UserParameter
User_Permission UserPermission

Users Integration

A system data scheduling model called 'Users.scheduling' exists to map Users and Permission Sets related to IFS PSO Workbench. Read more about Users Integration.

The Users.scheduling file can be found in the IFS Optimization Framework (FNDSCH) component. The model contains data fetch queries on tables such as fnd_user, fnd_role_role.


groups Groups {
    changedetection {
        trigger on FND_ROLE_TAB {
        objkey OBJKEY;

// Select all roles (granted roles) from fnd_role_role table, filtered by the granted_role
// - grantee_type of 'ROLE' and granted_role of 'FNDSCH_RUNTIME' (or any child roles of this).
// these will form the groups in IFS Scheduling, which are used to define 'groups of permissions' that users can be linked to (via UserGroup) - these// can be viewed as a similar notion to roles in IFS Cloud

        'FNDSCH_RUNTIME' id,
        NULL group_id
        FROM dual
        grantee id,
        granted_role group_id
    FROM fnd_role_role
    WHERE grantee_type='ROLE'
    START WITH granted_role = 'FNDSCH_RUNTIME'
    CONNECT BY PRIOR grantee = granted_role;

Note that in the above example of a data fetch within the security scheduling model 'Users.scheduling', there is a 'changedetection' section. This is added so that permission sets can be updated automatically in IFS PSO when updated in IFS Cloud.

However, the change detection for granted permission sets to users is implemented differently. A 'fulldiffonchange' needs to be implemented so that we make sure we send the correct matching of users to permission sets/groups to PSO. The reason for using 'fulldiffonchange' in this particular case is because the table 'SECURITY_SYS_ROLE_TREE_TAB' doesn't have an objkey. Using triggers based on objkey is recommended, however if not possible 'fulldiffonchange' can be used.

usergroup UserGroups {
    changedetection {
        trigger on FND_USER_ROLE_TAB {
        objkey OBJKEY;

For more detail of how this works please see section Change Detection.