Question:

When Service Request status is set to “Closed” then everything including all the child entities of Service Request should become read only but user should still be able to attachments.

OR

When SR status is set to “Close” all the child entities except “Service Request Attachments” should become read only.

Answer:

Service Request and all its child entities become “Read Only” as result of class based functionality of Service Request. So, we need to override the functionality and enable “Service Request Attachment” even after the status is changed to “Closed”. This can be achieved as following:

Define “Always Enable Child” User Property on Service Request BC will the following details:

Name: Always Enable Child: Service Request Attachment
Value: TRUE

There are lot of variations of this question such as:

1. There are two type of users, sales user and risk user. The Differentiating factor between them is User Type in Employee table. How can we configure that for risk user the records are editable and for sales user it is not.
2. How can a view be read only for a particular user and editable for the other user?

But in short we need to answer how to make a view read for some users and editable for some users.

Answer:

Create two responsibilities named Sales_User and Risk_User. Assign the view to both responsibilities and for Risk_User responsibility make “Read Only View” flag as true.

Now add sales users to Sales_User Responsibility and Risk Users to Risk_User Responsibility. Now for Risk_User records will be read only and for Sales user records will be editable.

Question: What are possible reasons of values not showing in dropdown of static Picklist?

Answer: The possible reason which could result in Picklist values not showing are

1. PickMap is not defined for Field which is showing Picklist values
2. LOV Type and LOV Values are not defined
3. Runtime Flag on Applet level is not true.
4. You have not clicked on Clear Cache after adding the values and trying to see values in same session.

If any of the above mentioned reason is true then you will not see the values in the dropdown of field

Question:

How to pupolate a field with the value of another field whenever a new record is created for the first time?

Answer:

Use Post Default Value property of the field using experssion to populate its value with another field value.

Example:

To populate value of  field “Sub Status” with value in field “Status” I would use  below given expression in Post Default value of “Sub Status” Field

Field: 'Status'

You can read more details about Post and Pre Default Properties from the link given below

http://siebelunleashed.com/pre-default-and-post-default-properties/

Incremental Compile: When we select a single object (BC, Applet etc), several objects (Multiple BC, Applets, BO etc), single project or several projects to compile in an existing SRF file that is known as Incremental Compile.

Full Compile: When you compile all the projects in a SRF file that is known as Full Compile.

::Difference::

SRF File: We do an Incremental compile on an existing SRF file and Full Compile results in creation of a New SRF file.

SRF Size: SRF size is more when we do an Incremental Compile as compared to Full Compile. For example if a Full Compile results in a 28 MB SRF file then an Incremental compile on that file can increase it’s size up to 32 MB

There are two types of toggle applet available in Siebel:

Static Toggle Applet: Which provides ability to user to manually select the applet that he wants to see from a dropdown list.

Dynamic Toggle Applet: In which applets are changed automatically based on a field value.

Tables in Siebel can be broadly classified into two types

• Repository Tables
• Data Tables

Repository Tables: Tables that are used to store Meta data about Siebel Objects are repository tables. Following are examples of Repository tables

S_APPLET: Stores Siebel Applets information
S_BUSCOMP: Stores Siebel Business Component Information
S_WFR_PROC: Stores Siebel Workflow Process Information

Data Table: Tables that are used to store Siebel User data are known as data tables. They can be further classified into following types

Base Tables: Stores data about various siebel entities such as opportunity, quotes service requests. Following are examples of Base Tables

S_OPTY: Used to store Opportunity Information
S_SRV_REQ: Used to store Service Request Information
S_EVT_ACT: Used to Activities Information
S_DOC_QUOTE: Used to store Quote Information

Extension Tables: These tables are extension of base tables and are connected via implicit join and are used to store custom information for various entities. They have _X suffix to their name

S_OPTY_X: Extension table for opportunities
S_DOC_QUOTE_X: Extension table for quotes
S_EVT_ACT_X: Extension table for activities

Interface Tables: Used export and import data from external applications. They have EIM prefix with table name. Every base table and extension table has its corresponding EIM tables. Examples of EIM Tables are

EIM_OPTY: Opportunity EIM Table
EIM_ACTIVITY: Activities EIM Table

XM Tables: These tables are used where M: M relationships have to be established. These tables have XM suffix after their name. Most of the base tables have corresponding XM tables. Examples of XM Tables are

S_OPTY_XM: XM table for Opportunity
S_DOC_QUOTE_XM: XM table for Quote

I know this is not an exhaustive list and there are some other terms for other types of table that are present in Siebel. Please help here by contributing to create a complete exhaustive list.

Purpose of both the Picklists is similar, to restrict or constraint the values of child Picklist based on the value of parent but we need to do different configuration to implement them.

The only reason I can think of using Constraint over Hierarchical Picklists is due to a limitation of Hierarchical Picklist showing all the values including child Picklist values.

Basic difference between Hierarchical and Constraint Picklist is as following:

Business Component:

Hierarchical Picklist (HPL): Business Component for HPL is Picklist Hierarchical
Constraint Picklist (CPL): Business Component for CPL is Picklist Generic

Values:

HPL: You will see all the values in Parent Picklist including Child Picklist Values
CPL: As both the parent and child fields have different Picklists associated there is no overlapping of values

LOV:

HPL: Same LOV is used for Parent as well as Child Picklist Field and Parent LIC field is used to establish a parent and child relationship
CPL: Different LOV is used for Parent and Child Fields.

I will try to explain the answer with the help of an example of  “Status” field.

We will assume the following values have been given for Pre-Default and Post-Default properties of Status Field

Pre-Default Value:  “In Process”
Post-Default Value:  “Complete”

Following are the scenarios which can take place:

User creates a New Record and saves the record without changing value of status field:
Pre-Default value (In Process) will be assigned to Status field.

User creates a New Record and changes the value of Status field to “Planning”
Pre-Default value is going to take effect as soon as user creates a new record but Post-Default value will not take effect. [Corrected as pointed by Gururaj]
User creates a New Record and changes the value of Status field to blank
Post Default Value (“Complete”) will take effect

User copies an existing record where value of status field is “Planning”
Neither Post-Default nor Pre-Default will take effect

User copies an existing record where value of status field is blank
Pre-Default (“In-Process”) Value will take effect

User copies an existing record  and makes the value of the field as blank
Post-Default Value (“Complete”) will take effect

User changes the value of existing record to blank and saves the record.
Neither Post-Default nor Pre-Default will take effect as these values only takes when the record is initially created and saved.

Click here to get more details about Pre-Default and Post Default properties

Links and Joins have following  differences

Relationship:
 
Joins: Joins are configured between a Business Component and a table.
Links: Links are configured between 2 Business Components. They represent Parent Child relationship Cardinality:
 
Joins: Joins have 1:1 & M:1 cardinality.
Links: Links have 1:M & M:M cardinality.
 
Configuration:
 
Joins: Joins are configured as child properties of a BC.
Links: Links are created through Link Object in Siebel tools and they are referenced in Business Objects and Multivalue Links (MVL) to establish parent child relationship.
 
Examples:
 
Joins: A Service Request can only have a single owner. So a Join is created in the Service Request BC to pull the owner information from the S_USER.
Links: An Account can have multiple Addresses. A link between BC: Account & BC: Business Address reflects this 1:M relationship.