Wednesday, May 13, 2009

Manager Visibility

Manager-based visibility is one of the toughest concepts for Siebel users to understand, and it also is a little tricky to simulate in a SQL-based query tool, so I thought I would post a summary of some of the basic concepts.

If I open a view with position-based team access control, such as one based on the Account business component, Sales Rep visibility returns all records where my position is on the sales team. By default, Manager visibility returns all those records, and also all records where one of my reports, direct or indirect, is primary on the sales team.

With single-position access control like with the Quote Bus Comp, Manager visibility returns all records associated with my position or with any of my reports positions.

With a business component such as Action, with person-based access control, records must be associated with my employee record or with the employee record of one of my reports. The reporting relationship is based on my currently active position. Subordinate positions must be the Primary Held Position of the subordinate's employee record for the employee to be included in the query. If the record has multiple owners, default functionality is to show only those records where the subordinate employee is the primary owner.

Views with Manager visibility can be based on business components that have a Person or Position type view mode. No special "Manager" view mode is required. Such views usually have names beginning "My Team's".

Person-based and position-based access control are based on a single relationship: between a position and it's parent position. Position is a party-based business component, and this relationship is defined on the S_PARTY table, with the column PAR_PARTY_ID joined to the parent record. Although every position can have only one parent, a position is subordinate to multiple positions for the purpose of manager visibility, because a position is subordinate to parent position's parent position, and etcetera. Therefore, manager visibility is actually based on an indeterminate number of iterations of the position/parent position relationship.

It would be extremely difficult to describe an unknown number of iterations of the position/parent position relationship with a single SQL statement. Siebel solves this problem by writing each position's reporting relationships to a table called S_PARTY_RPT_REL. A reporting relationship record is created for each related record, following the reporting chain through all iterations. This results in a many-to-many relationship, as each position can have many subordinate positions and each position can have a chain of parent and grandparent positions. Records in the S_PARTY_RPT_REL are created when a new record is inserted in S_POSTN, or when a user clicks on the "Generate Reporting Relationships" button in the Position administration view.

In a query to populate the My Teams view with data, S_PARTY_RPT_REL.PARTY_ID is set equal to the user's active position id. S_PARTY_RPT_REL.SUB_PARTY_ID joins to the applet's business component table and/or the sales team intersection table, depending on the business component.

For more about Manager visibility see the Siebel Security Guide in Siebel Bookshelf.

8 comments:

SiebelDev Noob said...

This was really useful, and came at a brilliant time for me, thank you for this great explanatory post on Manager Visibility!

Sri said...

Excellent Summary on a very difficult topic. Thanks so much !

Vivek said...

Thanks Jim for the nice topic on data visibility..

Joaquim Pichota said...

great thanks

Sasank Loka said...

Useful SQL to generate the Division Heirarchy for Manager Visibility : select CONNECT_BY_ROOT row_id prow_id,row_id,CONNECT_BY_ROOT from siebel.s_org_ext where INT_ORG_FLG = 'Y'
CONNECT BY NOCYCLE PRIOR row_id = PAR_DIVN_ID
START WITH row_ID
in
(
select distinct pn.bu_id
from siebel.s_org_ext o,siebel.s_contact c,siebel.s_user u, siebel.s_postn pn
where u.row_id=c.row_id and c.pr_held_postn_id = pn.row_id and pn.bu_id = o.row_id and c.provider_flg ='Y'
and o.INT_ORG_FLG = 'Y' and u.x_statcd = 'C' and pn.bu_id <> '0-R9NH'
)
) a

crackingsiebel.com said...

Hi All

For an enhanced introduction to Siebel Party Data Model, including its importance and Database characteristics, please refer the post at - http://crackingsiebel.com/2012/06/15/siebel-party-model-introduction/

If you want to know about Siebel Party Model - History and its impact on database architecture, please read out article at - http://crackingsiebel.com/2012/06/22/siebel-party-model-history/

To understand the concept of Parties, Party Types and their relationships in siebel, please refer to my post at CrackingSiebel: http://crackingsiebel.com/2012/06/29/siebel-party-model-party-and-party-types/

Regards
SS

crackingsiebel.com said...

Interested to know about Party Data Model in depth, including Practice Labs and details diagrams???

Click on to - http://crackingsiebel.com/2013/02/19/siebel-ebook-party-data-model/

Thanks
SS

Naveen Vyas said...

Superb Post mate. The explanation of Visibility mode for BC and also the way the reporting relationships are stored on the DB on S_PARTY_RPT_REL table has made it very easy to understand the manager visibility model. Good work, keep it up !!