Workflow Policies vs Workflow Processes

Building a solution with Siebel Workflow often involves the use of both Workflow Policies and Workflow Processes. Siebel Workflow, taken together, is a complete application for automating server processes defined using declarative relationships between logical objects. As a Siebel Developer, you need to understand the difference between a Workflow Policy and a Workflow Process.

A Workflow Process is a program that runs on the Siebel server. It is defined through a graphical interface as a set of steps. When the process runs, a single record is processed. The workflow process steps are performed as a series of data operations.

A Workflow Policy is a specific event that occurs on the Siebel database. Based on a database trigger, it can include many complex criteria, but it ultimately evaluates to a true/false condition to determine whether to execute a program or not. Commonly, a Workflow Policy will execute a Workflow Process.

Do not be confused between the Business Object that is part of the Workflow Process definition and the Workflow Policy Object that is part of the Workflow Policy definition. A Workflow Process runs on the business layer of the Siebel object model. The Business Object that helps define a Workflow Process is the same Business Object that governs the logical data entity relationships between Business Components in Siebel screens and views.

A Workflow Policy Object is also configured in Siebel Tools, and it also represents a logical data entity, but it seems closer to the data layer of the Siebel object model. Workflow Policy Objects, Components, Columns, and Component Columns are a objects that do not contain or enforce any business rules. They are essentially columns and tables, and the relationships between them.

By first understanding the basic differences between these two core components of Siebel Workflow, a Siebel Developer can begin to grasp the basics of the powerful business process automation application known as Siebel Workflow.

Interview Question #1 - What is a Link?

I've decided to add a new feature to this blog. With this post, I am introducing a series of interview questions that Siebel developers and development leads should consider when preparing for technical interviews. I've interviewed many developers, and I've been interviewed quite a few times as well, and I have a pretty good idea of what makes a good technical interview question.

When I interview someone, my questions are designed to discover what a candidate knows, not bolster my ego by proving that I know something the candidate doesn't. I focus on the fundamentals of Siebel configuration, allowing the candidate to demonstrate the depth of his or her knowledge.

Q: Please describe the Siebel configuration object called a "Link".

A: The candidate should be able to provide at least two of the following, but should not contradict any of them:

• A Link defines the relationship between Business Components.
• Links are used to define a Business Object; the relationships between the primary Business Component and other (child) Business Components in the Business Object are Links.
• A Link is not the same thing as a Multi-Value Link or a Multi-Value Group, but the definition of a Multi-Value Link does include a Link.
• A one-to-many Link makes a master-detail View possible.
• Links are defined on the Business Object layer, using Business Component Fields rather than Table Columns, although many-to-many links use Table and Column names to define the intersection table.
• The "Source" Field is on the Parent Business Component, while the "Destination" Field is on the Child Business Component.
• A Link can have a Search Specification.

It's ok to prompt the candidate with leading questions to develop a better understanding of the depth of his or her knowledge, asking open-ended questions wherever possible.

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.