OnDemand Web Services

CRM OnDemand
Siebel Web Services OnDemand

Guide
Version 5
(CRM OnDemand Release 10)
November 2005
Siebel Systems, Inc., 2207 Bridgepointe Parkway, San Mateo, CA 94404
Copyright © 2005 Siebel Systems, Inc.
All rights reserved.
Printed in the United States of America
No part of this publication may be stored in a retrieval system, transmitted, or reproduced in any way,
including but not limited to photocopy, photographic, magnetic, or other record, without the prior
agreement and written permission of Siebel Systems, Inc.
Siebel, the Siebel logo, UAN, Universal Application Network, Siebel CRM OnDemand, and other Siebel
names referenced herein are trademarks of Siebel Systems, Inc., and may be registered in certain
jurisdictions.
Other product names, designations, logos, and symbols may be trademarks or registered trademarks of
their respective owners.
PRODUCT MODULES AND OPTIONS. This guide contains descriptions of modules that are optional and
for which you may not have purchased a license. Siebel’s Sample Database also includes data related to
these optional modules. As a result, your software implementation may differ from descriptions in this
guide. To find out more about the modules your organization has purchased, see your corporate
purchasing agent or your Siebel sales representative.
U.S. GOVERNMENT RESTRICTED RIGHTS. Programs, Ancillary Programs and Documentation, delivered
subject to the Department of Defense Federal Acquisition Regulation Supplement, are “commercial
computer software” as set forth in DFARS 227.7202, Commercial Computer Software and Commercial
Computer Software Documentation, and as such, any use, duplication and disclosure of the Programs,
Ancillary Programs and Documentation shall be subject to the restrictions contained in the applicable
Siebel license agreement. All other use, duplication and disclosure of the Programs, Ancillary Programs
and Documentation by the U.S. Government shall be subject to the applicable Siebel license agreement
and the restrictions contained in subsection (c) of FAR 52.227-19, Commercial Computer Software -
Restricted Rights (June 1987), or FAR 52.227-14, Rights in Data—General, including Alternate III (June
1987), as applicable. Contractor/licensor is Siebel Systems, Inc., 2207 Bridgepointe Parkway, San
Mateo, CA 94404.
Proprietary Information
Siebel Systems, Inc. considers information included in this

documentation and in Siebel Online Help to be Confidential
Information. Your access to and use of this Confidential Information
are subject to the terms and conditions of: (1) the applicable Siebel
Systems software license agreement, which has been executed and
with which you agree to comply; and (2) the proprietary and
restricted rights notices included in this documentation.
Contents
Siebel Web Services OnDemand Guide 1
Chapter 1: What’s New in This Release
Chapter 2: Overview of Web Services OnDemand

About Web Services 9
OnDemand Web Services 10
XML API Security 11
XML API Reliability 12
Web Services and the OnDemand Objects 12
About Parent-Child Relationships 14
Behavior of Methods on Parent and Child Objects 15
Methods Called by the OnDemand Objects 15
OnDemand User Keys 15
OnDemand Status Keys 16
OnDemand Pick Maps 16
Audit Fields 17
Web Services OnDemand and Custom Fields 17
Field Types Supported by OnDemand 18
Locale-Dependent Access to OnDemand 18
Chapter 3: Getting Started with Web Services

Process of Setting Up Web Services OnDemand 19
Establishing and Managing the XML API Session 19
Logging In to the XML API Session 20
Integration Requests for the XML API Session 21
Logging Out of the XML API Session 21
Limits for the XML API Session 22
Code Samples for Logging In and Logging Out 23
Sample VB Code 24
Java Code Sample 26
C# Code Sample 30
Siebel Web Services OnDemand Guide Version 5 (CRM OnDemand Release 10) 3
Contents ■
Chapter 4: OnDemand Objects Exposed Through Web

Services
Parent Objects 33
Account 34
Activity 48
Campaign 54
Contact 60
Current User 73
CustomObject1 75
CustomObject2 83
Dealer 91
Household 93
Lead 98
LOV 102
Opportunity 104
Portfolio 113
Product 117
Product Category 120
Service Request 122
Solution 127
Territory 130
User 132
User Group 135
Vehicle 137
Child Objects 141
Address 142
Asset 142
Audit Trail 143
Competitor 143
Login History 143
Multiple Contact Roles 144
Note 144
Partner 144
Quota 145
Related Account 145
Related Contact 145
Revenue 145
Team 146
Chapter 5: Web Services OnDemand API Calls

API Calls 147
4 Siebel Web Services OnDemand Guide Version 5 (CRM OnDemand Release 10)
Contents ■
Delete 148
Insert 149
InsertOrUpdate 150
QueryPage 151
Update 156
Service API Calls 157
GetListOfValues 158
GetMapping 159
SetPasswordAPI 159
Appendix A: OnDemand XML API Samples

Query by Example Expression Samples 161
Query by Template Samples 164
Query by Children Samples 165
LOV Service Element Sample 170
Index
Contents ■
1 What’s New in This Release
Siebel Web Services OnDemand Guide contains new and previously released material.
What’s New in Siebel Web Services OnDemand Guide, Version 5

Table 1 lists new features in this version of the documentation to support Version 5
(CRM OnDemand Release 10).
Table 1. New Product Features in Siebel Web Services OnDemand Guide, Version 5
Topic Description
“About Parent-Child Relationships” The matrix table that details parent child relationships has
on page 14 been removed. This information is now contained in the
section that details each parent service and child component.
“Methods Called by the OnDemand The table that details the methods called by each service has
Objects” on page 15 been removed. This information is now contained in the
section that details each parent section.
“Logging Out of the XML API Extra information about logging out of the XML API session
Session” on page 21 has been added.
“Parent Objects” on page 33 Information on parent services of, child components of and
methods called by each service has been included for each
parent service.
“Account” on page 34 The revenue child component has been added to the account
service.
“Contact” on page 60 The revenue child component has been added to the contact
service.
“CustomObject1” on page 75 The CustomObject1 service is a new service that has been
added for this release, and is described in this section.
“CustomObject2” on page 83 The CustomObject2 service is a new service that has been
added for this release, and is described in this section.
“Dealer” on page 91 The dealer service is a new service that has been added for
this release, and is described in this section.
“Service Request” on page 122 A new method, ServiceRequestDelete, has been added to the
Service Request service.
What’s New in This Release ■
Table 1. New Product Features in Siebel Web Services OnDemand Guide, Version 5
Topic Description
“QueryPage” on page 151 A new parameter, UseChildAnd, has been added to all
QueryPage calls.
“GetMapping” on page 159 This is a new section that describes the GetMapping method.
2 Overview of Web Services
OnDemand
This chapter provides an overview of Siebel CRM OnDemand’s support for Web services. It contains
the following sections:
■ “About Web Services”
■ “Web Services and the OnDemand Objects” on page 12
■ “Field Types Supported by OnDemand” on page 18
About Web Services

The term Web services describes a standardized way of integrating Web-based applications over the
Web. Web services allow businesses to communicate with each other and with other clients, without
intimate knowledge of each other’s IT systems behind a firewall. Web services share business logic,
data, and processes through a Web services API. Application developers can then add the Web
services to a GUI (such as a Web page or executable program) to offer specific functionality to users.
Web Services Core Technologies

The Web services core technologies include:
■ Extensible Markup Language (XML): XML defines the structure and content of Web services. The
OnDemand Web Services objects and methods are defined using XML.
■ Web Services Description Language (WSDL): This is an XML-formatted language that is used to
describe the Web service’s capabilities, which allows applications to communicate effectively. The
WSDL file is an XML file that defines the objects and methods.
■ Simple Object Access Protocol (SOAP): SOAP is used to send Web services messages. Web
services messages are sent between the customer implementation of Web services and the SOAP
handler on the Siebel Web Server.
For more information on Web services technologies, see http://www.w3.org/2002/ws.
Siebel OnDemand Web Services Toolkit

A Siebel OnDemand Web Services Toolkit (Web Services Toolkit) is essentially composed of two core
parts:
■ SOAP Handler: This handler listens for incoming SOAP messages and invokes upon the
implementation (detailed below). It is also used to transfer the response back to the Web client.
■ Implementation: This is the actual implementation of the Web service that provides the core
functionality. This back-end implementation of the Web service is implemented in an Enterprise
Java Bean (EJB) file.
Overview of Web Services OnDemand ■ About Web Services
Figure 1 shows how the Web Services Toolkit interacts with the OnDemand database. The customer
uses the Web Services Toolkit (WSDLs) to define the objects and methods that are contained in the
OnDemand Hosted Service. The customer application communicates with OnDemand over the
Internet using the secure HTTPS protocol. It invokes the Web services implementation contained in
the OnDemand Hosted Service. The Web services implementation is used to create, update, delete,
or modify the objects that reside in the OnDemand database.
Figure 1. How Web Services Communicate with OnDemand
OnDemand Web Services

The Web Services Toolkit is a set of APIs that companies can use to build programs to integrate with
OnDemand. It provides a programmatic interface for accessing your company's Siebel CRM
OnDemand information. A customer application can use the Web Services Toolkit through standard
Web services development tools such as those provided by IBM's WebSphere, Microsoft's .NET, and
BEA's WebLogic. It exposes XML operations that interact with the components of Siebel CRM
OnDemand's online service.
Some common examples of client integrations include the following:
■ Integrations of CRM and back-office applications. You can retrieve real-time sales,
marketing, and service information from Siebel CRM OnDemand and use it in financial and other
back-office applications. For example, you can retrieve information about recently closed
opportunities through the Web services interface and insert this information into an order entry
system that has a Web services user interface. In addition, you can store information from back-
office applications in Siebel CRM OnDemand for instant access by end users, visible in custom
fields on any Siebel CRM OnDemand page.
Overview of Web Services OnDemand ■ About Web Services
■ Web-based portal applications. You can create customized Web-based applications using
Active Server Pages (ASPs), Java Server Pages (JSPs), or similar Web technology that accesses
Siebel CRM OnDemand through the Web services interface. For example, a Siebel CRM
OnDemand customer can deploy a customized Web form on its corporate Web site, allowing
visitors to enter requests for more information. The application creates new lead records in Siebel
CRM OnDemand for these requests through the Web services interface. Another Web page can
allow visitors to browse through solutions to common problems stored in Siebel CRM OnDemand
and retrieved in real time through the Web services interface.
■ Custom add-on modules. Customers can also extend Siebel CRM OnDemand functionality. For
example, a company may create a custom add-on module to streamline its unique quote creation
process, or a company may create additional utilities to perform mass data cleanup operations.
These modules access data in Siebel CRM OnDemand directly through the Web services interface.
OnDemand administrators and end users can run these modules while concurrently accessing the
Siebel CRM OnDemand user interface.
XML API Security

The Siebel CRM OnDemand Web Services Integration framework includes the following security
features:
■ All communications are encrypted with SSL for security (minimum 128-bit).
■ Access is session-based, requiring authorization with a valid Siebel CRM OnDemand user name
and password.
■ Inactive sessions are closed automatically after a period of inactivity.
■ The same data visibility and access capabilities that apply to users in the Siebel CRM OnDemand
hosted service are applied to users connected through the Web services interface. Data visibility
and access are restricted by the role that your company assigns. Permissions are checked for
every data access.
■ A full audit trail of Web services activity is available through Siebel CRM OnDemand's
Administration pages. These pages display both current and historical usage statistics.
■ A number of other proprietary solutions protect the system against malicious use of the Web
services interface. These solutions are constantly reviewed and improved as new technologies
and techniques become available.
The system creates a session with a standard HTTPS request to establish a connection with Siebel
CRM OnDemand through the Web services interface. A client creates a new session with the Login
operation and closes it with the Logoff operation. When a session is created, the system provides an
encrypted session identifier to the client. Security is maintained by the client including the session
identifier with each request during that session.
Overview of Web Services OnDemand ■ Web Services and the OnDemand Objects
XML API Reliability

All server components of Siebel CRM OnDemand, including those responsible for the Web services
interface, incorporate load balancing and other high-availability mechanisms. These mechanisms
prevent the service from being interrupted by server or network infrastructure failure.
Web Services and the OnDemand

Objects
Web services are a set of standards-based technologies that allow heterogeneous applications to
integrate with Siebel OnDemand. They provide the ability to publish, find, and invoke upon the core
Siebel OnDemand objects across the Web from any client application language. This makes the
process of using OnDemand objects very easy for those who want to use them.
The OnDemand objects provide a basis for customers to perform integration with OnDemand based
on SOAP technology. Table 2 details the OnDemand parent and child objects that are available
through OnDemand Web Services. For more information about parent-child relationships, see “About
Parent-Child Relationships” on page 14.
Table 2. OnDemand Objects—Parent Object Denoted by P
Object Description
“Account” on page 34 Stores information on companies with which your organization has a
(P) relationship, that is, customers, prospects, partners, and competitors.
“Activity” on page 48 Stores information on an activity that a user must carry out — for
(P) example, a call-back activity for an account. When an activity is created,
the end user must set the display field explicitly to Task or Appointment.
“Campaign” on Provides a mechanism for marketing products and services to customers

page 54 (P) and prospects.
“Contact” on page 60 Stores information on individuals with whom your organization has a
(P) relationship.
“Current User” on Stores information on the user who is currently logged in to the
page 73 (P) OnDemand system.
“CustomObject1” on Exposes the functionality of the CustomObject1 OnDemand object to

page 75 external applications.
“CustomObject2” on Exposes the functionality of the CustomObject2 OnDemand object to

page 83 external applications.
“Dealer” on page 91 Stores information about dealerships in the automotive industry.
“Household” on Stores financial details about a group of contacts that live in the same
page 93 household.
“Lead” on page 98 (P) Stores information on a company or individual with whom an opportunity
is created and worked.
Object Description
“LOV” on page 102 (P) Stores information on a list of values for a specified picklist.
“Opportunity” on Stores information on a potential revenue-generating event and is

page 104 (P) another type of information that you can use to manage accounts.
“Portfolio” on page 113 Stores information on the collection of financial services that you may
(P) provide to an account.
“Product” on page 117 Stores information on a product or service that your company provides to
(P) its customers.
“Product Category” on Stores information on groups of products that are related to each other.
page 120 (P)
“Service Request” on Stores information on requests made by customers of your organization.

page 122 (P)
“Solution” on page 127 Stores information on solutions to customer problems or service requests.
(P)
“Territory” on page 130 Stores information about the territory for which a user is responsible.
(P)
“User” on page 132 (P) Stores information on all the users of the system.
“User Group” on Stores information about groups of users.

page 135 (P)
“Vehicle” on page 137 Stores information on vehicles that may be sold to accounts or contacts.
(P)
“Address” on page 142 Stores information on the different addresses that are associated with
(C) accounts and contacts.
“Asset” on page 142 Stores information on the assets held by your accounts — for example,
(C) the products that an account has purchased.
“Audit Trail” on Stores information about how a service request object is modified from
page 143 (C) the moment that it created until a solution for the service request has
been found.
“Competitor” on Stores information on the competitor.

page 143 (C)
“Login History” on Stores information about currently logged in user such as the amount of
page 143 (C) times that the user has logged in, and the dates and times on which the
current user logged in.
“Multiple Contact Stores information on the different roles that a contact can hold within an
Roles” on page 144 (C) account.
“Note” on page 144 (C) Stores extra information (as a note) on a parent object.
“Partner” on page 144 Stores information on the partner.

(C)
Object Description
“Quota” on page 145 Stores information about the sales targets of, and sales made by the
(C) current user.
“Revenue” on page 145 Stores information about the product revenue for a particular opportunity.
(C)
“Related Account” on Stores information on an account that has a relationship with the parent
page 145 (C) account in question.
“Related Contact” on Stores information on an contact that has a relationship with the parent
page 145 (C) contact in question.
“Team” on page 146 Stores information on the team that is assigned to a particular account or
(C) contact.
About Parent-Child Relationships

Many of the OnDemand objects interact with each other through parent-child relationships. A parent
object refers to the main or base object of interest and the child object refers to objects that are
related to the parent in some way—for example, if the child object is contained in the parent, or if
the child object has records that refer to the parent object.
These parent-child relationships can be one-to-many or many-to-many. For example, a lead may be
associated with a particular account, but an account may have many leads associated with it. In this
case, the relationship between the account and its leads may be thought of as a one-to-many parent-
child relationship.
Other relationships may be many-to-many, meaning that many children may be associated with
many parents. For example, a contact may be associated with several opportunities, or an
opportunity may have several contacts associated with it. In this case, the relationship between
contacts and their opportunities may be thought of as a many-to-many parent-child relationship. The
parent-child relationship between contacts and opportunities may be treated with either the
opportunity as the parent with contacts as children, or with the contact as the parent and the
opportunities as children.
Behavior of Methods on Parent and Child Objects

Depending on whether an object is a parent or child object, Web services methods may act in
different ways on the object in question. Table 3 outlines how methods may act upon parent and child
objects to create or update an object instance.
Table 3. Effect of Methods on Parent and Child Objects
Existing Existing Missing

Method New Parent New Child Parent Child Child
Delete Error Error Removes Error Error

instance
Insert New parent New child Error Use child Not applicable
instance instance instance
InsertOrUpdate New parent New child Update Update child Child is

parent unchanged
Update Error New child Update Update child Child is

parent removed
Methods Called by the OnDemand Objects

There are a number of methods that may be called on the OnDemand objects. These methods are
detailed in Chapter 5, “Web Services OnDemand API Calls.” For information about the methods called
by each service, see the relevant section in Chapter 4, “OnDemand Objects Exposed Through Web
Services.”
OnDemand User Keys

User keys are subsets or groups of fields in an object table that can be used to uniquely identify a
record. A particular table or object may have any number of User Key subsets defined for records in
that table. The most basic subset of fields that identifies a record is the single field RowId (or primary
key field). Every record in the database has at least three of the following independent user keys:
RowId or primary key, IntegrationId, and ExternalSystemId. In addition, there are various field
combinations for different objects that can also be used to define uniqueness.
It is only possible to query for a particular record or update a particular record in a table, if the values
of all the fields in any user key subset is known. Any valid group of user keys can uniquely identify
the record that a user wants to query or update. For example, the RowId, IntegrationId, or
ExternalSystemId field of an object instance uniquely identifies a record, and the object table can be
queried using that field as the user key.
In some instances, the RowId, IntegrationId, or ExternalSystemId of a record may not be known,
but its name, description, or other unique identification information may be known. In these cases,
if a user key for a particular record is defined to be a subset of fields whose values are known, the
record can be successfully updated using this user key. For example, for a Note child object, the
Subject and Description fields can be used in conjunction with each other to determine whether the
record is unique or not. Such a combination is not guaranteed to provide complete uniqueness, but
it may be used to query for uniqueness.
Generally, a subset of the record’s fields are used as a user key. However, one field on its own may
also act as a user key, depending on whether the field can identify the record as unique. Each user
key group can be used independently to identify a record. The user keys for each object are detailed
for each object in Chapter 4, “OnDemand Objects Exposed Through Web Services.”
OnDemand Status Keys

An OnDemand status key is a field or a number of fields that is returned following an operation on
an OnDemand object. The status key of objects contained through the Web services API contains all
User Key and Audit fields in addition to some other fields that are identified as status keys for the
object. The status keys for the OnDemand objects are outlined in “Parent Objects” on page 33.
OnDemand Pick Maps

An OnDemand pick map allows you to set a foreign key for an object using a different object. For
example, when updating an account, you may want to set the owner of the account to a specific user.
If the UserId of the user is known it can be populated in the OwnerId field. However, if only the alias
of the user is known it can be populated in the Owner field. When OnDemand recognizes that the
Owner field has been set, it will automatically set the OwnerId to the UserId for the user. Pick maps
may be used by a number of OnDemand objects to update foreign key references in this way.
A list of pick map fields, and the fields that they map to, are detailed in “Parent Objects” on page 33
for each object.
Audit Fields
Audit fields on an object provide information about who created an instance of the object, when it
was created, who has updated an instance of the object, and when it was updated. All objects, both
parent and child level, exposed by the Web services API contain the read-only Audit fields contained
in Table 4.
Table 4. Audit Fields for the OnDemand Objects
Field Name Description
CreatedBy This field is a combination of the full name of the person that created this
instance of the object, and the date on which the instance was created. This
information is contained within the field in the following format:
“<Creator Full Name>, <CreatedDate>”
CreatedById The Row ID of the user that created the record.
CreatedDate The DateTime stamp of when the record was created.
ModifiedBy This field is a combination of the full name of the person that modified this
instance of the object, and the date on which the instance was modified. This
information is contained within the field in the following format:
“<Modified By Full Name>, <ModifiedDate>”
ModifiedById The Row ID of the user that last modified the record.
ModifiedDate The DateTime stamp of when the record was last modified.
Web Services OnDemand and Custom Fields

Siebel CRM OnDemand allows company administrators to create custom fields that capture
information specific to the company’s needs. Web Services OnDemand allows customers to interact
with the data stored in these custom fields. Each custom field has an associated integration tag that
is used by Web services and Web links to reference data in custom fields. This allows administrators
to change the display name of a field without the need to make modifications to the existing Web
services integration.
To view or modify integration tag information for an object

1 Navigate to the Field Setup Administration screen for the required object.
2 Click Advanced.
The integration tag information is displayed for you to view or modify.
To generate a WSDL file that is specific to your company’s customization

1 Navigate to the Web Services Administration screen.
Overview of Web Services OnDemand ■ Field Types Supported by OnDemand
2 Select the required object, and click Download.
An object’s WSDL that is specific to your company’s customization is downloaded.
Field Types Supported by OnDemand

All fields in Web services OnDemand are transmitted and received as strings. It is the client’s
responsibility to transform these to and from the required data type in any application. The proper
type can usually be determined from the name, purpose, or application of the field. There is no
dynamic method for determining field types. Clues about a field’s type can be derived from its name
as follows:
■ A name ending in the suffix Id is usually a key field such as primary key, foreign key, or user key
Id. It can usually be treated as a unique text string.
■ Fields with names containing Date or Time, such as LastUpdated, DueDate, StartTime, or
EndTime may be date fields. The format for these fields is determined by the user’s online
preferences settings.
■ Phone number fields can be treated as numeric phone numbers or as plain text.
■ Other numeric fields such as currency, size, revenue, or probability can be treated as integer,
floating point, or text fields depending on the application.
■ Boolean fields have value Y for true or N for false.
■ Most other fields can be treated as ordinary text.
Locale-Dependent Access to OnDemand

Siebel OnDemand Web Services does not provide any specialized localization interfaces. Siebel CRM
OnDemand supports full localization, so that the data created through Web services will be localized
for end users. The localized fields in the Web services interfaces follow the formats outlined in the
sections that follow.
Date and Time Fields

Date and time fields in OnDemand are in the following format:
MM/DD/YYYY hh:mm:ss
Number and Currency Fields

Number and currency fields in OnDemand are in raw number format. In other words, number and
currency fields hold only digits with no currency symbols, decimal separators, or other numeric
separators.
3 Getting Started with Web
Services
This chapter provides an overview of how to get started with Siebel CRM OnDemand Web Services
and contains the following sections:
■ “Process of Setting Up Web Services OnDemand” on page 19
■ “Establishing and Managing the XML API Session” on page 19
■ “Code Samples for Logging In and Logging Out” on page 23
Process of Setting Up Web Services

OnDemand
A customer who wants to access data in Siebel CRM OnDemand from a Web services-enabled client
must perform the following tasks:
1 Request Web Services Integration. For security reasons, this capability is not automatically
enabled for OnDemand customers. On request, a Siebel CRM OnDemand Customer Care
representative enables the Web Services OnDemand Integration capability for your company.
2 Download WSDL files. The customer's designated OnDemand Administrator accesses the Web
Services Administration page in Siebel CRM OnDemand. The Administrator downloads Web
Service Description Language (WSDL) files that have been published for the desired Siebel CRM
OnDemand entities.
3 Incorporate WSDL files. The company incorporates the WSDL files into its Web services
development environment—for example, by generating Java or C# (C Sharp) proxy classes.
4 Establishing and Managing the XML API Session. A Web services-enabled client, including
a client application written in any language that interacts with the Web services framework,
establishes a secure session with Siebel CRM OnDemand. Throughout this session, the client
interacts with the published OnDemand Web Service entities to perform data retrieval,
modification, creation, and deletion operations. OnDemand and the client format requests and
resulting data as standard XML/SOAP messages. For more information, see “Establishing and
Managing the XML API Session” on page 19.
Establishing and Managing the XML API

Session
The Web Service API for OnDemand integration is session-based. It has the following features:
■ Clients must make explicit login and logout calls in their code to manage the session.
■ The login step returns an HTTP cookie that must be used for making additional requests.
Getting Started with Web Services ■ Establishing and Managing the XML API Session
■ A session remains active until the user explicitly logs off or until the session times out.
Web services session management service is HTTP-based. Session management in Siebel CRM
OnDemand is based on a session ID, JSESSIONID, contained in HTTP Session Cookies. The session
ID is critical to successful session generation and maintenance of a SOAP transaction. OnDemand
Web Services enable session management by first creating a session using the login call, which is
then referenced in any subsequent SOAP operations.
In a Siebel SOAP session, the session ID may be referenced in one of these two ways (after it has
been created in a login request):
■ It may be attached as a parameter to the URL request line. When a session ID is present in the
URL line, it is identified by the string jsessionid in lowercase, followed by the exact session ID,
which is coded using URL syntax.
NOTE: This is the recommended approach to referencing the session ID.
■ It may be part of the cookie header line. When a session ID is referenced as a cookie, a cookie
header line must appear in the SOAP request with the name JSESSIONID=. In this case, the
session ID appears in uppercase, and the value of the cookie is exactly the same as the session
ID received from the login request.
SOAP operations will not work if a Siebel Session ID is not present in one of these ways.
When a login request is made, the session ID will be returned as a cookie in the response to the
request. The client is responsible for extracting this session ID and using it throughout the session.
If the session times out for any reason, the error returned will say the session is not valid and the
client must then request a new session. In this case no explicit logoff is required.
The logoff operation is considered one of the operations for a session, so the session ID must be
present in the logoff request. However, only the cookie version is accepted in the logoff request.
The OnDemand Web Service interface supports the following three types of functions:
■ “Logging In to the XML API Session”
■ “Integration Requests for the XML API Session” on page 21
■ “Logging Out of the XML API Session” on page 21
All requests must use SSL (HTTPS).
Logging In to the XML API Session

The Login request is an HTTPS request to instantiate a session and obtain a session ID. A client
invokes login by sending an HTTP GET to a URL like the following:
https://secure.crmondemand.com/Services/Integration?command=login
NOTE: The term login is case sensitive. The protocol https indicates the use of the SSL protocol.
Login input. The input to Login is provided in the URL parameters and the HTTP headers, as follows:
■ The only URL parameter to be set is command. This parameter value is login.
■ Two HTTP headers, UserName and Password, must be set with the appropriate values for your
system. For example:
UserName: johndoe@email.com
Password: mypass
Login output. Login returns the following items:
■ A session cookie, jsessionid. The client must use this cookie when submitting subsequent
requests, including logoff requests.
■ A status code of 200, if the session does not encounter any errors. This indicates that the request
succeeded.
Integration Requests for the XML API Session

An integration request is an HTTPS request to invoke a Web service. An integration request is made
by an HTTP POST to a URL like the following:
https://secure.crmondemand.com/Services/Integration/<EntityName>
where <EntityName> is the name of the relevant OnDemand entity. The system determines this
OnDemand entity from the contents of the SOAP request.
Integration request input. The jsessionid returned to the client during login must be included with
the request. The request must contain the jsessionid either as a cookie or as a URL parameter, as
follows:
https://secure.crmondemand.com/Services/Integration/<EntityName>;
jsessionid=xyZ12489w3482413
The Web service input is provided as a SOAP command in the body of the HTTP POST request.
Integration request output. The properties returned by the server populate the response headers
and the response body. The following table shows the top-level properties that specify key properties
of the HTTP response.
Property Comments
HttpStatus Status code returned in the response. If no value is provided, the response
is given the value 200 (indicating success).
Content-Type Content type returned in the response. If no value is provided, the response
is given the value text/xml.
Logging Out of the XML API Session

A client logs off by sending an HTTP POST or HTTP GET to a URL. For example:
https://secure.crmondemand.com/Services/Integration?command=logoff;
NOTE: Logoff is case sensitive.
Logoff input. The jsessionid returned to the client during login must be included with the request
as a cookie with the same name. There are no other URL parameters or HTTP headers, and there is
no HTTP body. The jsessionid returned to the client during login must be included with the request.
The request must contain the JSESSIONID as a cookie. It may not be passed in as a URL parameter.
Logoff output. Logoff has no output. If the session does not encounter any errors, the status code
of the response is 200. This indicates that the request succeeded.
Additional Logoff
The jsessionid can be included in the URL instead of a cookie if the user wants. The following URL is
what the user would use, where XXXX is the jsessionid.
https://secure.crmondemand.com/Services/Integration;jsessionid=XXXX?command=logoff
Limits for the XML API Session

The Siebel CRM OnDemand’s Web Services interface resources can be shared by multiple
organizations. Siebel CRM OnDemand provides a limiting infrastructure to make sure that some users
do not consume a disproportionate share of those resources. These limiters constrain customer
organizations’ use of server-side resources to equitably share available resources among users and
to minimize the possibility of denial-of-service incidents.
Number of Sessions Limit

Under some circumstances, a server may be flooded with concurrent logons. Siebel CRM OnDemand
provides session limiters that constrain the number of sessions an organization can have open at any
given time. This upper limit on the number of sessions applies to all open Web services sessions.
The upper limit on the number of open sessions per organization is based on the number of licensed
users within an organization. The system applies the following formula: If X represents the number
of users in an organization, then the organization's session quota is 2X + 10.
If traffic reaches the maximum number of permitted sessions, the following error message is
provided as a response to subsequent attempts to establish a session:
The maximum number of allowed simultaneous sessions has been exceeded.
This means that an end user will not be able to log on until some other sessions have ended.
Request Rate Limit

All integration requests (data exchange requests) in a session are subject to rate limiting. Rate
limiting is implemented for the following reasons:
■ A user may perform long-running operations on the server that result in complex and long-
running queries on the database.
■ A user may perform constant operations on the server that constantly use resources.
Getting Started with Web Services ■ Code Samples for Logging In and Logging Out
Rate limiting can alleviate the previous problems to some extent. OnDemand applies a restriction to
each session to limit the number of requests per second that clients can make. The rate limit is set
to twenty requests per second.
If the rate limit is exceeded, the following error message is provided to subsequent SOAP requests:
The maximum rate of requests was exceeded. Please try again in <waitTime> ms.
Request Size Limit

The upper limit on the size of any incoming HTTP request is 5 MB. If the request size is exceeded,
the following error message is provided to subsequent SOAP requests:
Request exceeded the size limit of 5 MB.
Session Timeouts
Web services sessions will time out after 5 minutes if there is no activity on the session.
Maximum Records Returned

For return messages the maximum number of records returned for each query is limited to 100. If
the requested records exceed this limit, an error of the following type is returned:
PageSize method argument cannot be greater than 100, specified by the server
parameter ‘MaximumPageSize’.
A response will never return more than the specified number of records for a parent object in a
request.
Maximum Objects in a Web Services Request

The maximum number of objects that can be sent in a single SOAP request is 20.
Code Samples for Logging In and

Logging Out
The following code samples illustrate how to login and logoff using VB, Java, and C#.NET code. These
samples are somewhat distinct from SOAP and are specific to Siebel CRM OnDemand Web Services.
For clarity and simplicity, the following samples do not include error detection and handling. The code
samples are detailed in the following sections:
■ “Sample VB Code” on page 24
■ “Java Code Sample” on page 26
■ “C# Code Sample” on page 30
Sample VB Code
The following sample is compatible with Visual Studio, Visual Basic 6.0.
' Declarations used to perform http internet communications from Visual Basic.
Declare Function InternetOpen Lib "WININET.DLL" Alias "InternetOpenA" ( _
ByVal lpszAgent As String, _
ByVal dwAccessType As Long, _
ByVal lpszProxyName As String, _
ByVal lpszProxyBypass As String, _
ByVal dwFlags As Long) As Long
Declare Function InternetConnect Lib "WININET.DLL" Alias "InternetConnectA" ( _
ByVal hInternetSession As Long, _
ByVal lpszServerName As String, _
ByVal nServerPort As Integer, _
ByVal lpszUserName As String, _
ByVal lpszPassword As String, _
ByVal dwService As Long, _
ByVal dwFlags As Long, _
ByVal dwContext As Long) As Long
Declare Function HttpSendRequest Lib "WININET.DLL" Alias "HttpSendRequestA" ( _
ByVal hHttpRequest As Long, _
ByVal lpszHeaders As String, _
ByVal dwHeadersLength As Long, _
ByVal lpOptional As String, _
ByVal dwOptionalLength As Long) As Integer
Declare Function InternetReadFile Lib "WININET.DLL" ( _
ByVal hFile As Long, _
ByRef lpBuffer As Any, _
ByVal dwNumberOfBytesToRead As Long, _
ByRef lpNumberOfBytesRead As Long) As Integer
Declare Function InternetCloseHandle Lib "WININET.DLL" ( _
ByVal hInternet As Long) As Boolean
' Adds one or more HTTP request headers to the HTTP request handle.
Declare Function HttpAddRequestHeaders Lib "WININET.DLL" Alias pAddRequestHeadersA" ( _
ByVal sHeaders As String, _
ByVal lHeadersLength As Long, _
ByVal lModifiers As Long) As Integer
Declare Function HttpQueryInfo Lib "WININET.DLL" Alias "HttpQueryInfoA" ( _
ByVal lInfoLevel As Long, _
ByRef sBuffer As Any, _
ByRef lBufferLength As Long, _
ByRef lIndex As Long) As Integer
' Define a function or sub to contain the login steps as defined here.
Dim netHeaders As String * 1024
Dim headerSize as long
' Open the internet connection.
m_hInternet = InternetOpen("ApplicationName", 0, vbNullString, vbNullString, 0)
m_hConnect = InternetConnect(m_hInternet, server, 443, sProxyUser, sProxyPwd, 3, 0,

0)
m_hRequest = HttpOpenRequest(m_hConnect, "GET", "/Services/

Integration?command=login", "HTTP/1.1", vbNullString, vbNullString, &H84A83000, 0)
sHeaders = "Accept-Language: en" & vbCrLf & _

"Connection: Keep-Alive" & vbCrLf & _
"UserName: email@address.com" & vbCrLf & _
"Password: userpassword"
result = HttpAddRequestHeaders(m_hRequest, sHeaders, Len(sHeaders), &HA0000000) '

Add headers
result = HttpSendRequest(m_hRequest, vbNullString, 0, vbNullString, 0)
headerSize = Len(netHeaders)
result = HttpQueryInfo(m_hRequest, &H16, ByVal netHeaders, headerSize, 0)
' Now parse netHeaders for header named JSESSIONID.
' This will be the value to use for the rest of the session.
' Then to Logoff, do the following:
m_hRequest = HttpOpenRequest(m_hConnect, "GET", ")/Services/

Integration?command=logoff", "HTTP/1.1", vbNullString, vbNullString, &H84A83000, 0)
sHeaders = "Accept-Language: en" & vbCrLf & _
"Connection: Keep-Alive" & vbCrLf & _
"Cookie: JSESSIONID=abc123:-1"
result = HttpAddRequestHeaders(m_hRequest, sHeaders, Len(sHeaders), &HA0000000) '

Add headers
result = HttpSendRequest(m_hRequest, vbNullString, 0, vbNullString, 0)
Java Code Sample

The following is a code sample for logging in and logging off using Java:
/*
* log on to a web services session at the passed in service provider location using
* the passed in credentials. return a session id string that can be used in later
* communication with the service provider in the event of a successful logon
* @param wsLocation - the location of the web services provider
* @param userName - OnDemand user name (email address) of the user we are logging
* in as
* @param password - password that corresponds to the userName parameter
* @return FAIL if the logon failed, session id string otherwise
*/
private static String logon(String wsLocation, String userName, String password)
String sessionString = FAIL;
try
// create an HTTPS connection to the OnDemand webservices
URL wsURL = new URL(wsLocation + "?command=login");
HttpURLConnection wsConnection = (HttpURLConnection)wsURL.openConnection();
// we don't want any caching to occur
wsConnection.setUseCaches(false);
// we want to send data to the server
// wsConnection.setDoOutput(true);
// set some http headers to indicate the username and password we are using to
logon
wsConnection.setRequestProperty("UserName", userName);
wsConnection.setRequestProperty("Password", password);
wsConnection.setRequestMethod("GET");
// see if we got a successful response
if (wsConnection.getResponseCode() == HttpURLConnection.HTTP_OK)
// get the session id from the cookie setting
sessionString = getCookieFromHeaders(wsConnection);
setSessionIdFromCookie(sessionString);
catch (Exception e)
System.out.println("Logon Exception generated :: " + e);
return sessionString;
/*
* log off an existing web services session, using the sessionCookie information
* to indicate to the server which session we are logging off of
* @param wsLocation - location of web services provider
* @param sessCookie - cookie string that indicates our sessionId with the WS provider
*/
private static void logoff(String wsLocation, String sessionCookie)
try
// create an HTTPS connection to the OnDemand webservices
URL wsURL = new URL(wsLocation + "?command=logoff");
HttpURLConnection wsConnection = (HttpURLConnection)wsURL.openConnection();
// we don't want any caching to occur
wsConnection.setUseCaches(false);
// let it know which session we're logging off of
wsConnection.setRequestProperty("Cookie", sessionCookie);
wsConnection.setRequestMethod("GET");
// see if we got a successful response
if (wsConnection.getResponseCode() == HttpURLConnection.HTTP_OK)
// if you care that a logoff was successful, do that code here
// showResponseHttpHeaders(wsConnection);
catch (Exception e)
System.out.println("Logoff Exception generated :: " + e);
/*
* given a successful logon response, extract the session cookie information
* from the response HTTP headers
* @param wsConnection successfully connected connection to OnDemand web services
* @return the session cookie string from the OnDemand WS session or FAIL if not found*
*/
private static String getCookieFromHeaders(HttpURLConnection wsConnection)
// debug code - display all the returned headers
String headerName;
String headerValue = FAIL;
for (int i=0; ; i++)
headerName = wsConnection.getHeaderFieldKey(i);
if (headerName != null && headerName.equals("Set-Cookie"))
// found the Set-Cookie header (code assumes only one cookie is being set)
headerValue = wsConnection.getHeaderField(i);
break;
// return the header value (FAIL string for not found)
return headerValue;
C# Code Sample
The following is a code sample for logging in and logging off using C# (C Sharp):
using System;
using System.Net;
using System.IO;
namespace WebServiceHandler
public class ManageSession
public static string SessionID = "";
public static String Login(String loginUrlString, String userName, String password,

StringBuilder output)
try
// create a http request and set the headers for authentication
HttpWebRequest myRequest = (HttpWebRequest)WebRequest.Create(loginUrlString);
HttpWebResponse myResponse;
myRequest.Method = "GET";
myRequest.Headers["UserName"] = userName;
myRequest.Headers["Password"] = password;
// Return the response.
myResponse = (HttpWebResponse)myRequest.GetResponse();
Stream sr = myResponse.GetResponseStream();
// retrieve session id
char[] sep = { ';' };
String[] headers = myResponse.Headers["Set-Cookie"].Split(sep);
for (int i=0; i <= headers.Length-1; i++)
if (headers[i].StartsWith("JSESSIONID"))
sep[0] = '=';
SessionID = headers[i].Split(sep)[1];
break;
sr.Close();
myResponse.Close();
catch (WebException webException)
catch (Exception e)
return SessionID;
public static void Logoff()
String logoffUrlString = serverName + "/Services/Integration?command=logoff";
HttpWebRequest req = (HttpWebRequest) WebRequest.Create(logoffUrlString);
req.Headers["Cookie: JSESSIONID"] = SessionID;
// make the HTTP call
HttpWebResponse resp = (HttpWebResponse) req.GetResponse();
if (resp.StatusCode != System.Net.HttpStatusCode.OK)
4 OnDemand Objects Exposed
Through Web Services
This chapter contains reference information about the objects exposed through the Web Services
OnDemand API. There are a number of parent and child OnDemand objects exposed. These objects
enable access to data stored within an instance of CRM OnDemand.
For each of these objects, there are a number of methods that may be invoked in order to carry out
a task or function. For more information on these methods, see Chapter 5, “Web Services OnDemand
API Calls.”
This chapter contains the following sections:
■ “Parent Objects”
■ “Child Objects” on page 141
Parent Objects
The discussion of the Web services parent objects includes a description of each object, as well as
information on usage of the objects and relationships between objects. The fields on which an object
can be filtered and the field combinations for user key identification are also listed.
The following OnDemand objects are detailed in this section:
■ “Account” on page 34
■ “Activity” on page 48
■ “Campaign” on page 54
■ “Contact” on page 60
■ “Current User” on page 73

■ “CustomObject1” on page 75
■ “CustomObject2” on page 83
■ “Dealer” on page 91
■ “Household” on page 93
■ “Lead” on page 98
■ “LOV” on page 102
■ “Opportunity” on page 104
■ “Portfolio” on page 113
■ “Product” on page 117
■ “Product Category” on page 120
OnDemand Objects Exposed Through Web Services ■ Parent Objects
■ “Service Request” on page 122
■ “Solution” on page 127
■ “Territory” on page 130
■ “User” on page 132
■ “User Group” on page 135
■ “Vehicle” on page 137
NOTE: The lists of Filterable Fields and User Key combinations for the child components are offered
only as a guide as they may change before the WSDLs are published.
Account
The account object exposes the data stored in the OnDemand account object and its related child
components. The methods of the account object require a list (array) of account objects as an input
argument. This list of accounts identifies the records on which the operation is to be carried out. This
section outlines the details of the account object and its relationship to its child objects.
Child Components
Activity, Contact, Lead, Opportunity, Service Request, Address, Asset, Competitor, Multiple Contact
Roles, Note, Partner, Related Account, Revenue and Team
Methods Called
Table 5 details the methods called by the account service, and their names as defined on the service.
Table 5. Methods Called by Account Service
Method Name Name as Defined on Service
“Delete” on page 148 AccountDelete
“GetMapping” on page 159 NA
“Insert” on page 149 AccountInsert
“InsertOrUpdate” on page 150 AccountInsertOrUpdate
“QueryPage” on page 151 AccountQueryPage
“Update” on page 156 AccountUpdate
Fields
Table 6 details the required and read-only fields for the account object.
Table 6. Required and Read-Only Fields for the Account Object
Child Component Field Name Type
Account AccountName Required
AccountConcatField Read-only
CreatedBy Read-only
CreatedById Read-only
ModifiedBy Read-only
ModifiedById Read-only
ModifiedDate Read-only
Multiple Contact ContactRole Required

Roles
ContactId Required
CreatedDate Read-only
CreatedBy Read-only
RelatedAccount AccountRelationshipId Read-only
RelatedAccountId Read-only
Revenue RevenueId Required
PartNumber Required
Revenue Required
ContactFullName Required
CreatedBy Read-only
Table 7 details the status key for the account object, and the child component on which this key
resides.
Table 7. Status Key for the Account Object
Child Component Field Name
Account CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedById
ModifiedDate
AccountNote CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
AccountTeam CreatedBy
CreatedById
CreatedDate
Id
ModifiedBy
ModifiedById
ModifiedDate
Activity CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Asset CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Competitor AccountCompetitorId
CompetitorExternalId
CompetitorId
CompetitorIntegrationId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
Contact AccountId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Lead AccountId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
LeadId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
Opportunity AccountId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
RelatedAccount AccountRelationshipId
CreatedByAndDate
CreatedByDate
CreatedById
ModifiedByAndDate
ModifiedById
ModifiedDate
Revenue CreatedBy
CreatedById
CreatedDate
ExternalId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
RevenueId
ServiceRequest AccountId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
ServiceRequestId
Partner AccountPartnerId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
PartnerExternalId
PartnerId
PartnerIntegrationId
Updated
Table 8 details the pick map fields for the account object and the child objects on which they reside.
Table 8. Pick Map Fields for the Account Object
Child Component Pick Map Field Maps To:
Account Owner OwnerId

ParentAccount, ParentAccountLocation ParentAccountId
ParentAccountIntegrationId ParentAccountId
Parent AccountExternalSystemId ParentAccountId
Table 8. Pick Map Fields for the Account Object
Competitor RelatedAccountExternalId RelatedAccountId
RelatedAccountIntegrationId RelatedAccountId
Contact ContactExternalId ContactId
ContactIntegrationId ContactId
Multiple Contact ContactIntegrationId ContactId

Roles
ContactExternalId ContactId
Partner RelatedAccountExternalId RelatedAccountId
Related Account RelatedAccountExternalId RelatedAccountId
Revenue Product ProductId
ProductExternalId ProductId
ProductIntegrationId ProductId
ProductCategory ProductCategoryId
ProductCategoryExternalId ProductCategoryId
ProductCategoryIntegrationId ProductCategoryId
Table 9 provides a list of the filterable fields for the child components of the account objects, and a
list of user key combinations for each child component. All parent fields on the account object are
filterable.
Table 9. Filterable Fields and User Key Fields on the Account Object’s Child Components
Child Components Filterable Fields User Key Field Combinations
Account All AccountId
IntegrationId
ExternalSystemId
AccountName and Location
Account Note Subject Subject and Description
Account Team FirstName FirstName and Last Name
LastName
UserID
UserRole
AccountAccess
OpportunityAccess
ContactAccess
ModifiedDate
ModifiedByID
Activity Type Type and Description
Owner
Subject
DueDate
Priority
Status
Address AddressId AddressId
ExternalId ExternalId
IntegrationId IntegrationId
City
Country
ModifiedDate
Province
StateProvince
ZipCode
Asset AssetId AssetId
Contract
Date
ModifiedDate
PartNumber
ProductCategory
Product
ProjectManager
PurchaseDate
Price
Quantity
SalesRep
SerialNumber
ShipDate
Status
Type
Warranty
Contact AccountContactModifiedById ContactId
AccountContactModifiedDate Id
ContactType
ContactFirstName
ContactId
ContactLastName
Id
JobTitle
Owner
RelationshipType
RelationshipModifiedDate
RelationshipModifiedById
Competitor ModifiedDate CompetitorId
Lead Campaign Id
EstimatedCloseDate LeadId
Rating
Source
Status
LeadOwner
PotentialRevenue
ProductInterest
SalesPerson
LeadId
Id
Multiple Contact Roles ContactId ContactId
ContactExternalId ContactIntegrationId
ContactIntegrationId ContactExternalId
ContactRole
ModifiedDate
Opportunity Owner OpportunityId
Revenue Id
CloseDate
Forecast
ExpectedRevenue
Probability
Priority
ReasonWonLost
SalesStage
Status
OpportunityId
Id
Related Account AccountRelationshipId AccountRelationshipId
Comments RelatedAccountId
EndDate RelatedAccountExternalId
ModifiedDate RelatedAccountIntegrationId
RelatedAccountExternalId
RelatedAccountId
RelatedAccountIntegrationId
RelationshipRole
RelationshipStatus
RelationshipType
ReverseRelationshipRole
StartDate
Revenue ContactFullName RevenueId
Description ProductId
ExternalId ProductExternalId
IntegrationId ProductIntegrationId
Forecast
Frequency
ModifiedDate
NumberOfPeriods
Product
ProductCategoryId
ProductCategoryExternalId
ProductCategoryIntegrationId
ProductExternalId
ProductId
ProductIntegrationId
PurchasePrice
Quantity
Revenue
RevenueId
StartCloseDate
Status
Type
Service Request Subject Id
Area ServiceRequestId
Owner
Priority
Type
Cause
Source
Status
Id
ServiceRequestId
Table 10 details the list of value fields available for the account object.
Table 10. Picklists Available for the Account Object
Child Component Field Name LOV Type
Account AccountType ACCOUNT_TYPE
Priority ACCOUNT_PRIORITY
Region TRAINING_LOC_REGION
CallFrequency PHMA_CALL_FREQUENCY
InfluenceType ACC_PRI_INFL_TYPE
Route PHMA_ROUTE
Status ACCOUNT_STATUS
MarketPotential PHMA_RATING
MarketingSegment PRIM_MARKET
Account Team TeamRole ACCOUNT_TEAM_TEAM_ROLE
Competitor Role PARTY_REL_TYPE
Multiple Contact ContactRole ACCOUNT_CONTACT_ROLE

Roles
Partner Role PARTY_REL_TYPE
RelatedAccount Relationship PARTY_REL_TYPE
Status PARTY_RELATIONSHIP_STATUS
Table 10. Picklists Available for the Account Object
Revenue Type REVENUE_TYPE
Status STATUS
Frequency LOV_FREQUENCY_TYPE
Table 11 details a number of account object fields that you must not use for customer integrations.
Table 11. Account Object Fields Not to Be Used
Field Name
CustomerAccountGroup
GroupTypeCode
InternalOrgFlag
For more information on the fields exposed through the account Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the account
object.
See Also
Contact
Activity
The activity object stores information on an activity that a user must carry out — for example, a call-
back activity for an account. When an activity is created, set the display field explicitly to Task or
Appointment.
Usage
Siebel OnDemand Web Services uses activities to organize, track, and resolve a variety of tasks, from
finding and pursuing opportunities to closing service requests. If a task requires multiple steps that
one or more people may carry out, activities greatly simplify the job. Activities can help:
■ Define and assign the task
■ Provide information to complete the task
■ Track the progress of the task
■ Track costs and bill for the task
Parent Services
Account, Campaign, Contact, Lead, Opportunity and Service Request
Child Components
Contact and User
Methods Called
Table 12 details the methods called by the activity service, and their names as defined on the service.
Table 12. Methods Called by Activity Service
“Delete” on page 148 ActivityDelete
“Insert” on page 149 ActivityInsert
“InsertOrUpdate” on page 150 ActivityInsertOrUpdate
“QueryPage” on page 151 ActivityQueryPage
“Update” on page 156 ActivityUpdate
Fields
Table 13 details the required and read-only fields for the activity object.
Table 13. Required and Read-Only Fields for the Activity Object

Activity Subject Required
Display Required
ActivityId Read-only
ContactFirstName Read-only
ContactLastName Read-only
LeadFirstName Read-only
LeadLastName Read-only
MedEdEventName Read-only
OpportunityName Read-only
FundRequest Read-only
Table 13. Required and Read-Only Fields for the Activity Object
Contact ContactId Read-only
ContactAccountId Read-only
ContactAccountName Read-only
ContactAccountLocation Read-only
ContactAccountIntegrationId Read-only
ContactAccountExternalSystemId Read-only
User UserId Read-only
UserEmail Read-only
UserFirstName Read-only
UserLastName Read-only
UserRole Read-only
Table 14 details the status key for the activity object.
Table 14. Status Key for the Activity Object
Activity ActivityId
CreatedBy
CreatedByAndDate
CreatedTimestamp
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedByAndDate
ModifiedTimestamp
Table 14. Status Key for the Activity Object
Contact ActivityContactId
ContactIntegrationId
ContactExternalSystemId
ContactId
CreatedByAndDate
CreatedById
CreatedDate
ModifiedByAndDate
ModifiedById
ModifiedDate
User CreatedByAndDate
CreatedById
CreatedDate
Id
ModifiedByAndDate
ModifiedById
ModifiedDate
UserExternalId
UserIntegrationId
Table 15 details the pick map fields for the activity object and the child objects on which they reside.
Table 15. Pick Map Fields for the Activity Object
Activity AccountName AccountId
AccountLocation AccountId
AccountExternalSystemId AccountId
AccountIntegration AccountId
Owner OwnerId
CampaignExternalSystemId CampaignId
CampaignIntegrationId CampaignId
CampaignName CampaignId
LeadExternalSystemId LeadId
LeadIntegrationId LeadId
MedEdEventExternalSystemId MedEdEventId
MedEdEventIntegrationId MedEdEventId
OpportunityExternalSystemId OpportunityId
OpportunityIntegrationId OpportunityId
ServiceRequestNumber ServiceRequestId
ServiceRequestExternalSystemId ServiceRequestId
ServiceRequestIntegrationId ServiceRequestId
FundRequestExternalSystemId FundRequestId
FundRequestIntegrationId FundRequestId
User UserExternalId UserId
UserIntegrationId UserId
Table 16 provides a list of the filterable fields for the child components of the activity objects, and a
list of user key combinations for each child component. All parent fields on the activity object are
filterable.
Table 16. Filterable Fields and User Key Fields on the Activity Object’s Child Components
Activity All ActivityId
IntegrationId
ExternalSystemId
Contact ContactId ContactId
ContactExternalId ContactExternalId
ContactIntegrationId ContactIntegrationId
ContactFirstName
ContactLastName
ContactAccountId
ContactAccountName
ContactAccountLocation
ContactAccountIntegrationId
ContactAccountExternalSystemId
ModifiedDate
User ModifiedDate UserId

UserId UserExternalId
UserExternalId UserIntegrationId
UserIntegrationId
UserEmail
UserFirstName
UserLastName
UserRole
Table 17 details the picklists available for the activity object.
Table 17. Picklists Available for the Activity Object
Field Name LOV Type
AccountName ACCOUNT_ID
AccountLocation ACCOUNT_ID
AccountIntegrationId ACCOUNT_ID
AccountExternalSystemId ACCOUNT_ID
OpportunityName OPPORTUNITY_ID
ServiceRequestNumber SERVICE_REQUEST_ID
ServiceRequestIntegrationId SERVICE_REQUEST_ID
ServiceRequestExternalSystemId SERVICE_REQUEST_ID
DelegatedByExternalSystemId DELEGATED_ID
PrimaryContactIntegrationId PRIMARY_CONTACT_ID
PrimaryContactExternalSystemId PRIMARY_CONTACT_ID
MedEdEventIntegrationId MED_ED_EVENT_ID
MedEdEventExternalSystemId MED_ED_EVENT_ID
FundRequestExternalId FUND_REQUEST_ID
LeadIntegrationId LEAD_ID
LeadExternalSystemId LEAD_ID
CampaignIntegrationId CAMPAIGN_ID
CampaignExternalSystemId CAMPAIGN_ID
ActivitySubtype COD_TODO_SUBTYPE
ResolutionCode COD_RESOLUTION_CODE
For more information on the fields exposed through the activity Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the activity
object.
Campaign
The campaign object provides a mechanism for marketing products and services to customers and
prospects. The campaign object is the primary way in which new products and services are marketed
to customers and prospects.
Parent Service
Lead
Child Components
Activity, Contact, Lead, Opportunity and Note
Methods Called
Table 18 details the methods called by the campaign service, and their names as defined on the
service.
Table 18. Methods Called by Campaign Service
“Delete” on page 148 CampaignDelete
“Insert” on page 149 CampaignInsert
“InsertOrUpdate” on page 150 CampaignInsertOrUpdate
“QueryPage” on page 151 CampaignQueryPage
“Update” on page 156 CampaignUpdate
Fields
Table 19 details the required and read-only fields for the campaign object.
Table 19. Required and Read-Only Fields for the Campaign Object
Field Name Type

CampaignName Required
SourceCode Required
CreatedBy Read-only
CreatedByFullName Read-only
LastUpdated Read-only
Table 20 details the status key for the campaign object.
Table 20. Status Key for the Campaign Object
Campaign CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Activity CampaignId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
CampaignNote CampaignId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Lead CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Opportunity CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Recipient CampaignContactId
ContactExtrernalId
ContactId
CreatedByAndDate
CreatedById
CreatedDate
ModifiedByAndDate
ModifiedById
ModifiedDate
Table 21 details the pick map field for the campaign object.
Table 21. Pick Map Field for the Campaign Object
Pick Map Field Maps To:
Owner OwnerId
Table 22 provides a list of the filterable fields for the child components of the campaign objects, and
a list of user key combinations for each child component. All parent fields on the campaign object
are filterable.
Table 22. Filterable Fields and User Key Fields on the Campaign Object’s Child Components
Campaign All CampaignId
IntegrationId
ExternalSystemID
Table 22. Filterable Fields and User Key Fields on the Campaign Object’s Child Components
Owner
Subject
DueDate
Priority
Status
Campaign Note Subject Subject and Description
Lead Campaign FirstName
EstimatedCloseDate Description
Rating
Source
Status
LeadOwner
PotentialRevenue
ProductInterest
SalesPerson
Opportunity Account OpportunityName
Owner
Revenue
CloseDate
Forecast
ExpectedRevenue
Probability
Priority
ReasonWonLost
SalesStage
Status
Table 23 details the picklists available for the campaign object.
Table 23. Picklists Available for the Campaign Object
Campaign CampaignType CAMPAIGN_TYPE
Status CAMPAIGN_STATE
Contact DeliveryStatus DELIVERY_STATUS
ResponseStatus RESPONSE_STATUS
For more information on the fields exposed through the campaign Web service, go to the Web
Services Administration screen within the OnDemand application and generate the WSDL for the
campaign object.
See Also
Current User and Opportunity
Contact
The contact object stores information on individuals with whom your organization has a relationship.
It allows the user to store information on individuals who are external to your company, but who are
associated with the business process. Contacts stored in the OnDemand database may also be
associated with an account.
Parent Services
Account, Activity, Campaign, Household, Opportunity, Portfolio and Vehicle
Child Components
Activity, Lead, Opportunity, Service Request, Note, Related Contact, Revenue and Team
Methods Called
Table 24 details the methods called by the contact service, and their names as defined on the service.
Table 24. Methods Called by Contact Service
“Delete” on page 148 ContactDelete
“Insert” on page 149 ContactInsert
“InsertOrUpdate” on page 150 ContactInsertOrUpdate
“QueryPage” on page 151 ContactQueryPage
“Update” on page 156 ContactUpdate
Fields
Table 25 details the required and read-only fields for the contact object.
Table 25. Required and Read-Only Fields for the Contact Object
Contact FirstName Required
LastName Required
ContactConcatField Read-only
ContactFullName Read-only
CreatedBy Read-only
Manager Read-only
Address AddressId Read-only
Contact Team ContactTeamId Read-only
UserRole Read-only
Table 25. Required and Read-Only Fields for the Contact Object
Related Contact ContactRelationshipId Read-only
ContactId Read-only
RelatedContactFirstName Read-only
RelatedContactLastName Read-only
Revenue RevenueId Required
PartNumber Required
Revenue Required
ContactFullName Required
CreatedBy Read-only
Table 26 details the status key for the contact object.
Table 26. Status Key for the Contact Object

Contact AccountId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Activity CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
ContactNote ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Lead AccountId
CampaignId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
LeadId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
LeadId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
RelatedContact ContactRelationshipId
CreatedByAndDate
CreatedByDate
CreatedById
ModifiedByAndDate
ModifiedByDate
ModifiedById
RelatedContactId
Revenue CreatedBy
CreatedById
CreatedDate
ExternalId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
RevenueId
ContactID
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
ServiceRequestId
Team ContactTeamId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
UserExternalSystemId
UserId
UserIntegrationId
Table 27 details the pick map fields for the contact object.
Table 27. Pick Map Fields for the Contact Object
Contact AccountName AccountId
Owner AssignedToAlias
SourceCampaignName SourceCampaignId
ManagerExternalSystemId ManagerId
Contact Team UserExternalSystemId UserId
Related Contact RelatedContactExternalId RelatedContactId
RelatedContactIntegrationId RelatedContactId
Revenue Product ProductId
ProductCategory ProductCategoryId
ProductCategoryExternalId ProductCategoryId
ProductCategoryIntegrationId ProductCategory
Table 28 provides a list of the filterable fields for the child components of the contact objects, and a
list of user key combinations for each child component. All parent fields on the contact object are
filterable.
Table 28. Filterable Fields and User Key Fields on the Contact Object’s Child Components
Contact All ContactId
IntegrationId
ExternalSystemId
Owner
Subject
DueDate
Priority
Status
Address AddressID AddressID
City
Country
ZipCode
StateProvince
Province
Contact Note Subject Subject and Description
Contact Team ContactTeamId
UserId
UserIntegrationId
UserFirstName
UserLastName
ContactAccess
UserRole
Lead Campaign
EstimatedCloseDate
Rating
Source
Status
LeadOwner
PotentialRevenue
ProductInterest
SalesPerson
LeadId
OpportunityId
Opportunity Opportunity
OpportunityId
Owner
Revenue
CloseDate
Forecast
ExpectedRevenue
Probability
Priority
ReasonWonLost
SalesStage
Status
Account
Personal Address PersonalAddressIntegrationId
PersonalAddressName
AlternateCity
AlternateCountry
AlternateZipCode
AlternateStateProvince
AlternateAddress
AlternateAddress2
AlternateAddress3
Id
IntegrationId
AddressName
City
Country
ZipCode
StateProvince
Address
ShippingAddress2
Related Contact ContactRelationshipId

RelatedContactId
RelatedContactExternalId
RelatedContactIntegrationId
RelationshipStatus
RelationshipType
StartDate
EndDate
Description
RelationshipRole
ReverseRelationshipRole
Revenue ContactFullName RevenueId
Description ExternalId
ExternalId IntegrationId
Forecast
Frequency
IntegrationId
ModifiedDate
NumberOfPeriods
Product
ProductId
ProductCategoryId
ProductCategory
ProductCategoryExternalId
ProductCategoryIntegrationId
ProductExternalId
ProductIntegrationId
PurchasePrice
Quantity
Revenue
RevenueId
Status
StartCloseDate
Type
Service Request Subject SRNumber
Area
Owner
Priority
Type
Cause
Source
Status
ServiceRequestId
Table 29 details the picklists available for the contact object.
Table 29. Picklists Available for the Contact Object
Contact ContactType CONTACT_TYPE
LeadSource OCCAM_LEAD_SOURCE
MrMrs MR_MRS
BestTimeToCall FINCORP_CONTACT_CALL_TIME
CallFrequency PROF_CALL_CLASS
CurrentInvestmentMix VONDINS_INVESTMENT_MIX
Degree PROF_DEGREE
ExperienceLevel FINS_INVST_EXPR_CD
Gender SEX_MF
InvestmentHorizon FINS_INV_HORIZON
LifeEvent FIN_CON_LIFE_EVENTS
MaritalStatus MARITAL_STATUS
MarketPotential PHARMA_MARKET_POT
Objective FINCORP_INVESTOR_OBJECTIVES
OwnOrRent FIN_HOUSING_TYPE
PrimaryGoal FINS_GOALS
RiskProfile FINS_INVST_RISK_CD
Route PROF_ROUTE
Segment FIN_CONTACT_DEPARTMENT
Tier FIN_CON_VALUE_TYPE
Contact Team TeamRole CONTACT_TEAM_TEAM_ROLE
Related Contact Relationship PARTY_REL_TYPE
Status CON_PARTY_RELATIONSHIP_STATUS
Revenue Type REVENUE_TYPE
Status STATUS
Frequency LOV_FREQUENCY_TYPE
Table 30 details a number of contact object fields that you must not use for customer integrations.
Table 30. Contact Object Fields That You Must Not Use
Field Name
PartyTypeCode
PartyUId
PersonUId
For more information on the fields exposed through the contact Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the contact
object.
Current User
The current user object stores information on the currently logged-in user.
Child Components
Login History and Quota
Methods Called
Table 31 details the method called by the current user service, and its name as defined on the
service.
Table 31. Methods Called by Current User Service

“QueryPage” on page 151 CurrentUserQueryPage
Fields
Table 32 details the required and read-only fields for the current user object.
Table 32. Required and Read-Only Fields for the Current User Object
Current User FirstName Required
LastName Required
CreatedBy Read-only
Login History LastLoggedIn Read-only
Table 33 provides a list of the filterable fields for the child components of the current user objects,
and a list of user key combinations for each child component. All parent fields on the current user
object are filterable.
Table 33. Filterable Fields on the Current User Object’s Child Components
Child Component XML Tag in WSDL User Key Field Combinations
Current User All CurrentUserId
IntegrationId
ExternalSystemId
FirstName and LastName and Middlename

Login History Alias
SourceIPAddress
SignInStatus
SignInTime
For more information on the fields exposed through the current user Web service, go to the Web
current user object.
See Also
User
CustomObject1
This service exposes the functionality of the CustomObject1 OnDemand object to external
applications.
NOTE: To download the CustomObject1 WSDL, you must be given access to the CustomObject1
object. If you do not have access to the CustomObject1 object, it will not be available to download
from the Web Services Administration screen or available to use the vertical Web service calls. For
assistance in gaining access to the CustomObject1 object, contact your Siebel CRM OnDemand
service provider.
Child Components
Account, Contact, CustomObject2, Opportunity, Portfolio and Team
Methods Called
Table 34 details the methods called by the CustomObject1 service, and their names as defined on
the service.
Table 34. Methods Called by CustomObJect1 Service
“Delete” on page 148 CustomObject1Delete
“Insert” on page 149 CustomObject1Insert
“InsertOrUpdate” on page 150 CustomObject1OrUpdate
“QueryPage” on page 151 CustomObject1Page
“Update” on page 156 CustomObject1Update
Fields
Table 35 details the required and read-only fields for the CustomObject1 object.
Table 35. Required and Read-Only Fields for the CustomObject1 Object
CustomObject1 CustomObject1Id Required
CustomObject1ExternalSystemID Required
CustomObject1IntegrationId Required
CustomObject1Id Read-only
Account CObj1AccountCreatedById Read-only
CObj1AccountCreatedDate Read-only
CObj1AccountModifiedById Read-only
CObj1AccountModifiedDate Read-only
Region Read-only
AccountType Read-only
Contact CObj1ContactCreatedById Read-only
CObj1ContactCreatedDate Read-only
CObj1ContactModifiedById Read-only
CObj1ContactModifiedDate Read-only
ContactType Read-only
CustomObject2 CObj1CustomObject2CreatedById Read-only
CObj1CustomObject2CreatedDate Read-only
CObj1CustomObject2ModifiedById Read-only
CObj1CustomObject2ModifiedDate Read-only
Opportunity AccountName Read-only

CObj1OpportunityCreatedById Read-only
CObj1OpportunityCreatedDate Read-only
CObj1OpportunityModifiedById Read-only
CObj1OpportunityModifiedDate Read-only
Revenue Read-only
SalesStage Read-only
Portfolio AccountNumber Read-only
CObj1PortfolioCreatedById Read-only
CObj1PortfolioCreatedDate Read-only
CObj1PortfolioModifiedById Read-only
CObj1PortfolioModifiedDate Read-only
Revenue Read-only
Team CustomObject1TeamId Read-only
Table 36 details the status key for the CustomObject1 object.
Table 36. Status Key for the CustomObject1 Object
CustomObject1 CustomObject1Id
ExternalSystemId
IntegrationId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
Account CustomObject1AccountId
CObj1AccountCreatedById
CObj1AccountCreatedDate
CObj1AccountModifiedById
CObj1AccountModifiedDate
Contact CustomObject1ContactId
CObj1ContactCreatedById
CObj1ContactCreatedDate
CObj1ContactModifiedById
CObj1ContactModifiedDate
CObj1CustomObject2CreatedById
CObj1CustomObject2CreatedDate
CObj1CustomObject2ModifiedById
CObj1CustomObject2ModifiedDate
Opportunity OpportunityId
CObj1OpportunityCreatedById
CObj1OpportunityCreatedDate
CObj1OpportunityModifiedById
Portfolio PortfolioId
CObj1PortfolioCreatedById
CObj1PortfolioCreatedDate
CObj1PortfolioModifedById
CObj1PortfolioModifiedDate
Team CustomObject1TeamId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
Table 37 details the pick map fields for the CustomObject1 object.
Table 37. Pick Map Fields for the CustomObject1 Object
CustomObject1 AccountExternalId AccountId
AccountIntegrationId AccountId
AccountName AccountId
ActivityExternalId ActivityId
ActivityIntegrationId ActivityId
ActivityName ActivityId
CampaignExternalId CampaignId
ContactFirstName ContactId
ContactFullName ContactId
ContactLastName ContactId
CustomObject2ExternalId CustomObject2Id
CustomObject2IntegrationId CustomObject2Id
CustomObject2Name CustomObject2Id
DealerName DealerId
HouseholdExternalId HouseholdId
HouseholdIntegrationId HouseholdId
HouseholdName HouseholdId
LeadExternalId LeadId
LeadFirstName LeadId
LeadFullName LeadId
CustomObject1 LeadLastName LeadId

(contd.)
Owner OwnerId
OpportunityExternalId OpportunityId
OpportunityName OpportunityId
ParentExternalSystemId ParentId
ParentIntegrationId ParentId
PortfolioAccountNumber PortfolioId
ProductName ProductId
SolutionExternalId SolutionId
SolutionIntegrationId SolutionId
SolutionTitle SolutionId
ServiceRequestExternalId ServiceRequestId
ServiceRequestName ServiceRequestId
VIN VehicleId
Account ExternalSystemId AccountId

IntegrationId AccountId
Location AccountId
Name AccountId
Contact ExternalSystemId ContactId
IntegrationId ContactId
CustomObject2 Owner OwnerId
Opportunity ExternalSystemId OpportunityId
IntegrationId OpportunityId
Portfolio ExternalSystemId PortfolioId
IntegrationId PortfolioId
Team UserExternalSystemId UserId
UserEmail UserId
Table 38 provides a list of the filterable fields for the child components of the CustomObject1 object,
and a list of user key combinations for each child component. All parent fields on the CustomObject1
Table 38. Filterable Fields and User Key Fields on the CustomObject1 Object’s Child Components
CustomObject1 All CustomObject1Id
ExternalSystemId
IntegrationId
Account AccountId CustomObject1AccountId
AccountType ExternalSystemId
CObj1AccountModifiedById IntegrationId
ExternalSystemId
IntegrationId
Location
Name
Region
Contact ContactId CustomObject1ContactId
CObj1ContactModifiedById ExternalSystemId
CObj1ContactModifiedDate IntegrationId
ContactType
ExternalSystemId
IntegrationId
CustomObject2 CustomObject2Id CustomObject2Id
CObj1CustomObject2ModifiedById ExternalSystemId
CObj1CustomObject2ModifiedDate IntegrationId
ExternalSystemId
IntegrationId
Name
Type
Opportunity CObj1OpportunityModifiedById OpportunityId
CObj1OpportunityModifiedDate ExternalSystemId
ExternalSystemId IntegrationId
IntegrationId
OpportunityId
Portfolio CObj1PortfolioModifiedById PortfolioId
CObj1PortfolioModfiedDate ExternalSystemId
IntegrationId
PortfolioId
Team CustomObject1TeamId CustomObject1TeamId
UserEmail UserExternalSystemId
UserExternalSystemId UserIntegrationId
UserId
UserIntegrationId
Table 39 details the picklist available for the CustomObject1 object.
Table 39. Picklists Available for the CustomObject1 Object
Dealer Type OCC_CUST_LOV_ACCOUNT_0 to

OCC_CUST_LOV_ACCOUNT_99
Household Type OCC_CUST_LOV_HOUSEHOLD_0 to

OCC_CUST_LOV_HOUSEHOLD_99
Portfolio Type OCC_CUST_LOV_ASSET_0 to

OCC_CUST_LOV_ASSET_99
Vehicle Type OCC_CUST_LOV_ASSET_0 to

CustomObject2
This service exposes the functionality of the CustomObject2 OnDemand object to external
applications.
NOTE: To download the CustomObject2 WSDL, you must be given access to the CustomObject2
object. If you do not have access to the CustomObject2 object, it will not be available to download
from the Web Services Administration screen or available to use the vertical Web service calls. For
assistance in gaining access to the CustomObject2 object, contact your Siebel CRM OnDemand
service provider.
Child Components
Account, Contact, CustomObject1, Opportunity, Portfolio and Team
Methods Called
Table 40 details the methods called by the CustomObject2 service, and their names as defined on
the service.
Table 40. Methods Called by CustomObJect2 Service
“Delete” on page 148 CustomObject2Delete
“Insert” on page 149 CustomObject2Insert
“InsertOrUpdate” on page 150 CustomObject2OrUpdate
“QueryPage” on page 151 CustomObject2Page
“Update” on page 156 CustomObject2Update
Fields
Table 41 details the required and read-only fields for the CustomObject2 object.
CustomObject1 CustomObject2Id Required
CustomObject2ExternalSystemID Required
CustomObject2IntegrationId Required
Account AccountType Read-only
CObj2AccountCreatedById Read-only
CObj2AccountCreatedDate Read-only
CObj2AccountModifiedById Read-only
CObj2AccountModifiedDate Read-only
Region Read-only
Contact ContactFirstName Read-only
ContactType Read-only
CObj2ContactCreatedById Read-only
CObj2ContactCreatedDate Read-only
CObj2ContactModifiedById Read-only
CObj2ContactModifiedDate Read-only
CustomObject1 CObj2CustomObject1CreatedById Read-only
CObj2CustomObject1CreatedDate Read-only
CObj2CustomObject1ModifiedById Read-only
CObj2CustomObject1ModifiedDate Read-only
Opportunity AccountName Read-only
CObj2OpportunityCreatedById Read-only
CObj2OpportunityCreatedDate Read-only
CObj2OpportunityModifiedById Read-only
CObj2OpportunityModifiedDate Read-only
Name Read-only
Revenue Read-only
SalesStage Read-only
Portfolio AccountNumber Read-only
CObj2PortfolioCreatedById Read-only
CObj2PortfolioCreatedDate Read-only
CObj2PortfolioModifiedById Read-only
CObj2PortfolioModifiedDate Read-only
Revenue Read-only
Team CustomObject2TeamId Read-only
Table 42 details the status key for the CustomObject2 object.
ExternalSystemId
IntegrationId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
Account CustomObject2AccountId
CObj2AccountCreatedById
CObj2AccountCreatedDate
CObj2AccountModifiedById
Contact CustomObject2ContactId
CObj2ContactCreatedById
CObj2ContactCreatedDate
CObj2ContactModifiedById
CObj2ContactModifiedDate
CObj2CustomObject1CreatedById
CObj2CustomObject1CreatedDate
CObj2CustomObject1ModifiedById
CObj2CustomObject1ModifiedDate
Opportunity OpportunityId
CObj2OpportunityCreatedById
CObj2OpportunityModifiedById
Portfolio PortfolioId
CObj2PortfolioCreatedById
CObj2PortfolioCreatedDate
CObj2PortfolioModifedById
CObj2PortfolioModifiedDate
Team CustomObject2TeamId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
Table 43 details the pick map fields for the CustomObject2 object.
CustomObject2 AccountExternalId AccountId
AccountName AccountId
ActivityExternalId ActivityId
ActivityIntegrationId ActivityId
ActivityName ActivityId
CampaignExternalId CampaignId
ContactFirstName ContactId
ContactFullName ContactId
ContactLastName ContactId
CustomObject2 CustomObject3Name CustomObject3Id

(contd.)
DealerName DealerId
HouseholdExternalId HouseholdId
HouseholdIntegrationId HouseholdId
HouseholdName HouseholdId
LeadExternalId LeadId
LeadFirstName LeadId
LeadFullName LeadId
LeadLastName LeadId
Owner OwnerId
OpportunityExternalId OpportunityId
ParentExternalSystemId ParentId
ParentIntegrationId ParentId
PortfolioAccountNumber PortfolioId
ProductName ProductId
SolutionExternalId SolutionId
SolutionIntegrationId SolutionId
SolutionTitle SolutionId
ServiceRequestExternalId ServiceRequestId
ServiceRequestName ServiceRequestId
VIN VehicleId
Account ExternalSystemId AccountId
IntegrationId AccountId
Location AccountId
Name AccountId
Contact ExternalSystemId ContactId
IntegrationId ContactId
CustomObject1 Owner OwnerId
Opportunity ExternalSystemId OpportunityId
IntegrationId OpportunityId
Portfolio ExternalSystemId PortfolioId
IntegrationId PortfolioId
Team UserExternalSystemId UserId
UserEmail UserId
Table 44 provides a list of the filterable fields for the child components of the CustomObject2 object,
and a list of user key combinations for each child component. All parent fields on the CustomObject2
CustomObject2 All CustomObject2Id
ExternalSystemId
IntegrationId
Account AccountId CustomObject2AccountId
AccountType ExternalSystemId
CObj2AccountModifiedById IntegrationId
ExternalSystemId
IntegrationId
Location
Name
Region
Contact CObj2ContactModifiedById CustomObject2ContactId
CObj2ContactModifiedDate ExternalSystemId
ContactId IntegrationId
ContactType
ExternalSystemId
IntegrationId
CustomObject1 CObj2CustomObject1ModifiedById CustomObject1Id
CObj2CustomObject1ModifiedDate ExternalSystemId
CustomObject1Id IntegrationId
CustomObject1Name
ExternalSystemId
IntegrationId
Type
Opportunity CObj2OpportunityModifiedById OpportunityId
CObj2OpportunityModifiedDate ExternalSystemId
IntegrationId
OpportunityId
Portfolio CObj2PortfolioModifiedById PortfolioId

CObj2PortfolioModfiedDate ExternalSystemId
IntegrationId
PortfolioId
Team CustomObject2TeamId CustomObject2TeamId
UserEmail UserExternalSystemId
UserExternalSystemId UserIntegrationId
UserId
UserIntegrationId
Table 45 details the picklist available for the CustomObject2 object.
Dealer Type OCC_CUST_LOV_ACCOUNT_0 to

Household Type OCC_CUST_LOV_HOUSEHOLD_0 to

OCC_CUST_LOV_HOUSEHOLD_99
Portfolio Type OCC_CUST_LOV_ASSET_0 to

Vehicle Type OCC_CUST_LOV_ASSET_0 to

Dealer
The dealer object stores information about dealerships in the automotive industry, for example, the
name of the dealership, the identity of the parent dealership, the site on which the dealership is
based, and so on. The dealer object does not have any parent services or child components.
NOTE: To download the Dealer WSDL, you must be given access to the Dealer object. If you do not
have access to the Dealer object, it will not be available to download from the Web Services
Administration screen or available to use the vertical Web service calls. For assistance in gaining
access to the Dealer object, contact your Siebel CRM OnDemand service provider.
Methods Called
Table 46 details the methods called by the dealer service, and their names as defined on the service.
Table 46. Methods Called by Dealer Service
“Delete” on page 148 DealerDelete
“Insert” on page 149 DealerInsert
“InsertOrUpdate” on page 150 DealerInsertOrUpdate
“QueryPage” on page 151 DealerQueryPage

“Update” on page 156 DealerUpdate
Fields
All fields on the dealer object are filterable.
Table 47 details the required and read-only fields for the dealer object.
Table 47. Required and Read-Only Fields for the Dealer Object
Field Name Type
DealerId Required
DealerIntegrationId Required
DealerExternalSystemID Required
DealerId Read-only
DealerType Read-only
Table 48 details the status key for the dealer object.
Table 48. Status Key for the Dealer Object
Dealer CreatedBy
CreatedById
CreatedDate
DealerId
DealerIntegrationID
DealerExternalSystemId
ModifiedBy
ModifiedById
ModifiedDate
Table 49 details the pick map fields for the dealer object.
Table 49. Pick Map Fields for the Dealer Object
Owner OwnerId
ParentDealerExternalSystemId ParentDealerId
Table 49. Pick Map Fields for the Dealer Object
ParentDealerIntegrationId ParentDealerId
ParentDealerName ParentDealerId
ParentDealerSite ParentDealerId
Table 50 details the picklists available for the dealer object.
Table 50. Picklists Available for the Dealer Object
Field Name LOV Type
ParentDealerName ParentDealerId
ParentDealerSite ParentDealerId
For more information on the fields exposed through the household Web service, go to the Web
household object.
Household
The household object allows you to define and record financial details about a group of contacts that
live in the same household, for example, parents, brothers, sisters, spouses, and so on. These details
include the assets of the household, the liabilities of the household, the net income of the household,
and so on.
NOTE: To download the Household WSDL, you must be given access to the Household object. If you
do not have access to the Household object, it will not be available to download from the Web
Services Administration screen or available to use the vertical Web service calls. For assistance in
gaining access to the Household object, contact your Siebel CRM OnDemand service provider.
Child Component
Contact
Methods Called
Table 51 details the methods called by the household service, and their names as defined on the
service.
Table 51. Methods Called by Household Service
“Delete” on page 148 HouseholdDelete
“Insert” on page 149 HouseholdInsert
“InsertOrUpdate” on page 150 HouseholdInsertOrUpdate
“QueryPage” on page 151 HouseholdQueryPage
“Update” on page 156 HouseholdUpdate
Fields
Table 52 details the required and read-only fields for the household object.
Table 52. Required and Read-Only Fields for the Household Object
Household HouseholdName Required
IntegrationID Required
ExternalSystemID Required
HouseholdId Read-only
PrimaryContactId Read-only
PrimaryContactExternalId Read-only
PrimaryContactIntegrationId Read-only
PrimaryContactFirstName Read-only
PrimaryContactLastName Read-only
Timezone Read-only
HouseholdCurrency Read-only
LastActivity Read-only
HeadDOB Read-only
TotalIncome Read-only
TotalAssets Read-only
TotalExpenses Read-only
TotalLiabilities Read-only
TotalNetWorth Read-only
RiskProfile Read-only
ExperienceLevel Read-only
InvestmentHorizon Read-only
CurrentInvestmentMix Read-only
Objective Read-only
PrimaryGoal Read-only
Table 52. Required and Read-Only Fields for the Household Object
Contact ContactId Required
ContactExternalId Required
ContactIntegrationId Required
ContactId Read-only
ContactMrMrs Read-only
Table 53 details the status key for the household object.
Table 53. Status Key for the Household Object
Household CreatedBy
CreatedById
CreatedDate
ExternalSystemId
HouseholdId
IntegrationID
ModifiedBy
ModifiedById
ModifiedDate
Contact CreatedBy
CreatedById
CreatedDate
ContactId
ModifiedBy
ModifiedById
ModifiedDate
Table 54 details the pick map fields for the household object.
Table 54. Pick Map Field for the Household Object
Table 55 provides a list of the filterable fields for the child components of the household object, and
a list of user key combinations for each child component. All parent fields on the household object
are filterable.
Table 55. Filterable Fields and User Key Fields on the Household Object’s Child Components
Household All HouseholdId
IntegrationID
ExternalSystemID
Contact ContactID ContactID
ModifiedDate
RelationshipRole
Table 56 details the picklists available for the household object.
Table 56. Picklists Available for the Household Object
Household Segment HOUSEHOLD_SEGMENT
Type HOUSEHOLD_TYPE
Contact RelationshipRole REL_TO_HOUSEHOLD
For more information on the fields exposed through the household Web service, go to the Web
household object.
Lead
The lead object stores information on a company or individual with whom an opportunity may be
created and worked. It allows the user to identify the companies that may be interested in a product
or service. Leads are usually generated as part of a marketing campaign.
Parent Services
Account, Campaign, Contact and Opportunity
Child Components
Activity and Campaign
Methods Called
Table 57 details the methods called by the lead service, and their names as defined on the service.
Table 57. Methods Called by Lead Service
“Delete” on page 148 LeadDelete
“Insert” on page 149 LeadInsert
“InsertOrUpdate” on page 150 LeadInsertOrUpdate
“QueryPage” on page 151 LeadQueryPage
“Update” on page 156 LeadUpdate
Fields
Table 58 details the required and read-only fields for the lead object.
Table 58. Required and Read-Only Fields for the Lead Object
Field Name Type
FirstName Required
LastName Required
LeadOwner Required
CreatedBy Read-only
Table 58. Required and Read-Only Fields for the Lead Object
Field Name Type
LeadConcatField Read-only
LeadFullName Read-only
Table 59 details the status key for the lead object.
Table 59. Status Key for the Lead Object
Lead AccountId
CampaignId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
Table 59. Status Key for the Lead Object
Activity CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LeadId
ModifiedBy
ModifiedById
ModifiedDate
Table 60 details the pick map fields for the lead object.
Table 60. Pick Map Fields for the Lead Object
Campaign CampaignId
Owner OwnerId
OpportunityExternalSystemId OpportunityId
ContactExternalSystemId ContactId
CampaignExternalSystemId CampaignId
Table 61 provides a list of the filterable fields for the child components of the lead object, and a list
of user key combinations for each child component. All parent fields on the lead object are filterable.
Table 61. Filterable Fields and User Key Fields on the Lead Object’s Child Components
Lead All LeadId
IntegrationId
ExternalSystemId
LeadFirstName and LeadLastName
Description
Owner
Subject
DueDate
Priority
Status
Table 62 details the picklists available for the lead object.
Table 62. Picklists Available for the Lead Object
Field Name LOV Type
Country COUNTRY
MrMrs MR_MRS
Rating OCCAM_LEAD_RATING
Source OCCAM_LEAD_SOURCE
StateProvince STATE_ABBREV
Status OCCAM_LEAD_SOURCE
For more information on the fields exposed through the lead Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the lead object.
Siebel Web Services OnDemand Guide Version 5 (CRM OnDemand Release 10) 10 1
LOV
The LOV object stores information on a list of values for a specified static picklist. Using the
GetListOfValues method with this object allows a user to return a list of values for a static drop-down
list. For example, if you want to get a list of all the possible types that an Activity can have, you use
the GetListOfValues method with the LOVType parameter set to TODO_TYPE. This returns all possible
values for the type of a Task.
There are three fields—OpportunitySalesStage, ContactTimeZone, and AccountIndustry—that are
not implemented as a standard LOV field. For this reason, the GetListOfValues method cannot be
used to return values for these fields.
Table 63 shows the fields for which LOVs are available for each object. This table also details the LOV
type for the field. The LOV type determines the items available in the picklist.
Table 63. Web Services Fields for Which LOVs Are Available
Object Field Name LOV_TYPE
Account AccountType ACCOUNT_TYPE
Custom Picklist OCC_CUST_LOV_ACCOUNT_0 through

Region TRAINING_LOC_REGION
Activity Custom Picklist OCC_CUST_LOV_ACTION_0 through

OCC_CUST_LOV_ACTION_99
Asset Custom Picklist OCC_CUST_LOV_REVN_0 through

OCC_CUST_LOV_REVN_99
Type PRODUCT_TYPE
Operating Status
Campaign CampaignType CAMPAIGN_TYPE
Custom Picklist OCC_CUST_LOV_CAMPAIGN_0 through

OCC_CUST_LOV_CAMPAIGN_99
Status CAMPAIGN_STATE
Contact ContactType CONTACT_TYPE
Custom Picklist OCC_CUST_LOV_CONTACT_0 through

OCC_CUST_LOV_CONTACT_99
MrMrs MR_MRS
Lead Country COUNTRY
Custom Picklist OCC_CUST_LOV_LEAD_0 through

OCC_CUST_LOV_LEAD_99
MrMrs MR_MRS
Rating OCCAM_LEAD_RATING
Source OCCAM_LEAD_SOURCE
StateProvince STATE_ABBREV
Status OCCAM_LEAD_STATUS
Opportunity Custom Picklist OCC_CUST_LOV_OPTY_0 through

OCC_CUST_LOV_OPTY_99
Probability PROB
ReasonWonLost REASON_WON_LOST
Status OPTY_STATUS
Product Status IMPL_PHASE
ProductType PROD_CD
BodyStyle AUTO_BODY_STYLE_TYPE
DoorStyle AUTO_DOORS_STYLE_TYPE
Engine AUTO_ENGINE_TYPE
Make OD_AUTO_MAKE_TYPE
Model OD_AUTO_MODEL_TYPE
Transmission AUTO_TRANSMISSION_TYPE
Trim OD_AUTO_TRIM_TYPE
Category PRODUCT_CATEGORY
PriceType UNIT_OF_MEASURE
SubType FINS_ASSET_PROD_CLASS_MLOV
TherapeuticClass THERAPEUTIC_CLASS
Service Request Area SR_AREA
Cause SR_SEVERITY
Custom Picklist OCC_CUST_LOV_SR_0 through

OCC_CUST_LOV_SR_99
Priority SR_PRIORITY
Source SR_SOURCE
Status SR_STATUS
Type SR_TYPE
Solution Custom Picklist OCC_CUST_LOV_SOLUTION_0 through

OCC_CUST_LOV_SOLUTION_99
Publish SOLUTION_PUBLISH
Status SOLUTION_STATUS
Methods Called
Table 64 details the method called by the LOV service, and its name as defined on the service.
Table 64. Methods Called by LOV Service
“GetListOfValues” on page 158 LOVGetListOfValues
Opportunity
The opportunity object allows employees to identify and record a potential revenue-generating event
that has arisen with an account or contact. Opportunities can be generated from marketing
campaigns when leads indicate that they are interested in a product or service that has been offered.
Parent Services
Account, Campaign and Contact
Child Components
Activity, Contact, Lead, Product, Note and Revenue
Methods Called
Table 65 details the methods called by the opportunity service, and their names as defined on the
service.
Table 65. Methods Called by Opportunity Service
“Delete” on page 148 OpportunityDelete
“Insert” on page 149 OpportunityInsert
“InsertOrUpdate” on page 150 OpportunityInsertOrUpdate
“QueryPage” on page 151 OpportunityQueryPage
“Update” on page 156 OpportunityUpdate
Fields
Table 66 details the required and read-only fields for the opportunity object.
Table 66. Required and Read-Only Fields for the Opportunity Object
Opportunity AccountId Required
CloseDate Required
OpportunityName Required
SalesStage Required
CreatedBy Read-only
OpportunityConcatField Read-only
Table 66. Required and Read-Only Fields for the Opportunity Object
ProductRevenue ProductRevenueId Read-only
ProductCategoryId Read-only
ProductCategory Read-only
ProductPartNumber Read-only
ProductStatus Read-only
ProductType Read-only
OpportunityId Read-only
OpportunityIntegrationID Read-only
OpportunityExternalSystemId Read-only
OpportunitySalesStage Read-only
OpportunityAccountId Read-only
OpportunityAccountName Read-only
OpportunityAccountLocation Read-only
OpportunityAccountExternalSystemId Read-only
OpportunityAccountIntegrationId Read-only
Table 67 details the status key for the opportunity object.
Table 67. Status Key for the Opportunity Object
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Activity CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
Contact AccountId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
Lead AccountId
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
LastUpdated
LeadId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
OpportunityNote CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
OpportunityId
Product CreatedBy
CreatedByDate
CreatedById
ExternalId
ProductRevenueId
IntegrationID
ModifiedBy
ModifiedById
ModifiedDate
Table 68 details the pick map fields for the opportunity object.
Table 68. Pick Map Fields for the Opportunity Object
Opportunity Owner OwnerId
Territory TerritoryId
Table 68. Pick Map Fields for the Opportunity Object
ProductRevenue ProductName ProductId
ProductExternalSystemId ProductId
ContactExternalSystemId ContactId
Owner OwnerId
Table 69 provides a list of the filterable fields for the child components of the opportunity objects,
and a list of user key combinations for each child component. All parent fields on the opportunity
Table 69. Filterable Fields and User Key Fields on the Opportunity Object’s Child Components
Opportunity All OpportunityId
IntegrationId
ExternalSystemId
Owner
Subject
DueDate
Priority
Status
Contact ContactType AccountName and Private
ContactFirstName ContactFirstName and

ContactLastName and Private
JobTitle
ContactLastName
Owner
Id
Lead Campaign
EstimatedCloseDate
Rating
Source
Status
LeadOwner
PotentialRevenue
ProductInterest
SalesPerson
LeadId
Note Subject Subject and Description
Product OpportunityIntegrationId OpportunityExternalSystemId
OpportunityExternalSystemId OpportunityIntegrationId
OpportunitySalesStage
OpportunityAccountId
OpportunityAccountName
OpportunityAccountLocation
OpportunityAccountExternalSystemId
OpportunityAccountIntegrationId
ModifiedDate
ContactId
ContactExternalSystemId
Contract
OwnerId
Owner
SerialNumber
Revenue
ExpectedRevenue
Quantity
PurchasePrice
Product (contd.) PurchaseDate
StartCloseDate
NumberOfPeriods
Frequency
Probability
Forecast
AssetValue
Premium
ShipDate
Status
Type
Warranty
ProductRevenue ProductRevenueId ProductRevenueId
ProductId
ProductName
ProductExternalSystemID
ProductionIntegrationId
ProductCategoryId
ProductCategory
ProductPartNumber
ProductStatus
ProductType
OpportunityId
OpportunityName
Table 70 details the list of value fields available for the opportunity object.
Table 70. Picklists Available for the Opportunity Object
Opportunity LeadSource OCCAM_LEAD_SOURCE
Probability PROB
ReasonWonLost REASON_WON_LOST
Status OCCAM_LEAD_STATUS
Type UT_OPPTY_TYPE
Year YEAR
Product Frequency LOV_FREQUENCY_TYPE
Probability % PROB
Status STATUS
TYPE REVENUE_TYPE
Warranty LOV_WARRANTY_TYPE
Contract LOV_CONTRACT_TYPE
For more information on the fields exposed through the opportunity Web service, go to the Web
opportunity object.
Portfolio
The portfolio object allows you to define and record details about the collection of financial services
that you may provide to an account. Financial services include loans, credit cards, insurance, general
banking, and so on.
NOTE: To download the Portfolio WSDL, you must be given access to the Portfolio object. If you do
not have access to the Portfolio object, it will not be available to download from the Web Services
access to the Portfolio object, contact your Siebel CRM OnDemand service provider.
Child Component
Contact
Methods Called
Table 71 details the methods called by the portfolio service, and their names as defined on the
service.
Table 71. Methods Called by Portfolio Service
“Delete” on page 148 PortfolioDelete
“Insert” on page 149 PortfolioInsert
“InsertOrUpdate” on page 150 PortfolioInsertOrUpdate
“QueryPage” on page 151 PortfolioQueryPage
“Update” on page 156 PortfolioUpdate
Fields
Table 72 details the read-only fields for the portfolio object and its child component.
Table 72. Read-Only Fields on the Portfolio Object
Portfolio PortfolioId Read-only
Owner Read-only
OwnerId Read-only
PrimaryContact Read-only
CreatedBy Read-only
Table 72. Read-Only Fields on the Portfolio Object
Contact ContactId Read-only
ContactHomePhone Read-only
ContactEmail Read-only
CreatedBy Read-only
Table 73 details the status key for the portfolio object.
Table 73. Status Key for the Portfolio Object
Portfolio CreatedBy
CreatedById
CreatedDate
ExternalSystemId
PortfolioId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Table 73. Status Key for the Portfolio Object
Owners ContactId
CreatedBy
CreatedById
CreatedDate
Id
ModifiedBy
ModifiedById
ModifiedDate
Table 74 details the pickmap fields for the portfolio object and its child objects.
Table 74. Pick Map Fields for the Portfolio Object
Portfolio InstitutionExternalId InstitutionId
InstitutionIntegrationId InstitutionId
InstitutionName InstitutionId
InstitutionLocation InstitutionId
Product ProductId
Table 75 provides a list of the filterable fields and user key combinations for the child components of
the portfolio object. All parent fields on the portfolio object are filterable.
Table 75. Filterable Fields and User Key Fields on the Portfolio Object’s Child Components
Portfolio All PortfolioId
IntegrationId
ExternalSystemId
Table 75. Filterable Fields and User Key Fields on the Portfolio Object’s Child Components
ContactFirstName
ContactLastName
ContactHomePhone
ContactEmail
PrimaryInsured
NamedInsured
PolicyOwner
Relationship
Table 76 details the picklists available for the portfolio object.
Table 76. Picklists Available for the Portfolio Object
Portfolio AccountType FINS_ASS_LIAB_ALL_LIF_PLC_MLOV
Status IMPL_PHASE
TermUnit FINS_CD_INTEREST_FREQ_MLOV
Contact Relationship CC_CLSE_ACCT_LOV_CD
For more information on the fields exposed through the portfolio Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the portfolio
object.
See Also
Contact
Product
The product object allows you to define and record details about a product or service that your
company sells to its customers, including information on product price, category, and so on. The
product object does not have any child objects.
Parent Services
Account, Campaign and Contact
Child Components
Activity, Contact, Lead, Product, Note and Revenue
Methods Called
Table 77 details the methods called by the product service, and their names as defined on the service.
Table 77. Methods Called by Product Service
“Insert” on page 149 ProductInsert
“InsertOrUpdate” on page 150 ProductInsertOrUpdate
“QueryPage” on page 151 ProductQueryPage
“Update” on page 156 ProductUpdate
Fields
All fields on the product object are filterable.
Table 78 details the required and read-only fields for the product object.
Table 78. Required and Read-Only Fields for the Product Object
Field Name Type
ProductName Required
CreatedBy Read-only
Table 79 details the status key for the product object.
Table 79. Status Key for the Product Object
Product Id
IntegrationId
ModifiedById
ModifiedDate
Table 80 details the pick map field for the product object.
Table 80. Pick Map Field for the Product Object
ParentCategory ParentCategoryId
Table 81 details the user keys for the product object.
Table 81. User Keys for the Product Object
Product ProductId
IntegrationId
ExternalSystemId
Table 82 details the list of value fields available for the product object.
Table 82. List Of Values Fields Available for the Product Object
Field Name LOV Type
BodyStyle AUTO_BODY_STYLE_TYPE
Category PRODUCT_CATEGORY
Class PRODUCT_TYPE
DoorStyle AUTO_DOORS_STYLE_TYPE
Table 82. List Of Values Fields Available for the Product Object
Field Name LOV Type
PriceType UNIT_OF_MEASURE
ProductType PROD_CD
Revision FINS_PROD_STATUS_VERSION_MLOV
Status IMPL_PHASE
SubType FINS_ASSET_PROD_CLASS_MLOV
TherapeuticClass THERAPEUTIC_CLASS
For more information on the fields exposed through the product Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the product
object.
See Also
Product Category
Product Category
The product category object allows you to logically sort products into groups, where each product is
in some way related to the other products in the category. The product category object does not have
any child objects.
Methods Called
Table 83 details the methods called by the product category service, and their names as defined on
the service.
Table 83. Methods Called by Product Category Service

“Delete” on page 148 ProductCategoryDelete
“Insert” on page 149 ProductCategoryInsert
Table 83. Methods Called by Product Category Service
“InsertOrUpdate” on page 150 ProductCategoryInsertOrUpdate
“QueryPage” on page 151 ProductCategoryQueryPage
“Update” on page 156 ProductCategoryUpdate
Fields
All fields on the product category object are filterable.
Table 84 details the required and read-only fields for the product category object.
Table 84. Required and Read-Only Fields for the Product Category Object
Field Name Type
CategoryName Required
CreatedBy Read-only
ModifiedByFullName Read-only
Table 85 details the status key for the product category object.
Table 85. Status Key for the Product Category Object
AdminProductLine Id
IntegrationId
ModifiedById
ModifiedDate
Name
Table 86 details the pick map field for the product object.
Table 86. Pick Map Field for the Product Category Object
ParentCategory ParentCategoryId
Table 87 details the user keys for the product category object.
Table 87. User Keys for the Product Category Object
Product ProductCategoryId
IntegrationId
ExternaSystemId
Name
For more information on the fields exposed through the product category Web service, go to the Web
product category object.
See Also
Product
Service Request
The service request object allows customers to request information or assistance with a problem
related to products or services purchased from your company. Service requests may be ranked for
severity and prioritized accordingly.
Parent Services
Account, Contact and Solution
Child Components
Activity, Solution, Audit Trail and Note
Methods Called
Table 88 details the methods called by the service request service, and their names as defined on the
service.
Table 88. Methods Called by Service Request Service
“Delete” on page 148 ServiceRequestDelete
“Insert” on page 149 ServiceRequestInsert
“InsertOrUpdate” on page 150 ServiceRequestInsertOrUpdate
“QueryPage” on page 151 ServiceRequestQueryPage
“Update” on page 156 ServiceRequestUpdate
Fields
Table 89 details the required and read-only fields for the service request object.
Table 89. Required and Read-Only Fields for the Service Request Object
Field Name Type
ContactEmail Read-only
CreatedBy Read-only
ServiceRequestConcatId Read-only
Table 90 details the status key for the service request object.
Table 90. Status Key for the Service Request Object
ContactId
CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Activity CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
Table 90. Status Key for the Service Request Object
ServiceRequestNote CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
ServiceRequestId
Solution CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Table 91 details the pick map fields for the service request object.
Table 91. Pick Map Fields for the Service Request Object
Owner OwnerId
AssetIntegrationId AssetId
AssetExternalSystemId AssetId
ProductExternalSystemId ProductId
Table 92 provides a list of the filterable fields for the child components of the service request object,
and a list of user key combinations for each child component. All parent fields on the service request
Table 92. Filterable Fields and User Key Fields on the Service Request Object’s Child Components
Child Component Filterable Fields User Key Field Combinations
Service Request All ServiceRequestId
IntegrationId
ExternalSystemId
SRNumber
Owner
Subject
DueDate
Priority
Status
Audit Trail Date
User
FieldModified
Service Request Note Subject Subject and Description
Solution Title Title

Published
SolutionId
Status
Id
Table 93 details the list of value fields available for the service request object.
Table 93. Picklists Available for the Service Request Object
Field Name LOV Type
Area SR_AREA
Cause SR_SEVERITY
Table 93. Picklists Available for the Service Request Object
Field Name LOV Type
Source SR_SOURCE
Status SR_STATUS
Type SR_TYPE
For more information on the fields exposed through the service request Web service, go to the Web
service request object.
Solution
The solution object stores information on solutions to customer problems or service requests.
Solutions can be reused if the same problem is identified with a product or service. This prevents
duplication of work for customer service representatives.
Parent Service
Service Request
Child Component
Service Request
Methods Called
Table 94 details the methods called by the solution service, and their names as defined on the
service.
Table 94. Methods Called by Solution Service
“Delete” on page 148 SolutionDelete
“Insert” on page 149 SolutionInsert
“InsertOrUpdate” on page 150 SolutionInsertOrUpdate

“QueryPage” on page 151 SolutionQueryPage
“Update” on page 156 SolutionUpdate
Fields
Table 95 details the required and read-only fields for the solution object.
Table 95. Required and Read-Only Fields for the Solution Object
Field Name Type
Title Required
CreatedBy Read-only
CreatorId Read-only
Table 96 details the status key for the solution object.
Table 96. Status Key for the Solution Object
Solution CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Table 96. Status Key for the Solution Object
ServiceRequest CreatedBy
CreatedById
CreatedDate
ExternalSystemId
Id
IntegrationId
LastUpdated
ModifiedBy
ModifiedById
ModifiedDate
Table 97 provides a list of the filterable fields for the child components of the solution objects, and a
list of user key combinations for each child component. All parent fields on the solution object are
filterable.
Table 97. Filterable Fields and User Key Fields on the Solution Object’s Child Components
Solution All SolutionId
IntegrationId
ExternalSystemId
Service Request Subject SRNumber
Area
Owner
Priority
Type
Cause
Source
Status
Table 98 details the list of value fields available for the solution object.
Table 98. Picklists Available for the Solution Object
Field Name LOV Type
Area SR_AREA
Cause SR_SEVERITY
Source SR_SOURCE
Status SR_STATUS
Type SR_TYPE
For more information on the fields exposed through the solution Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the solution
object.
See Also
Service Request
Territory
The territory object allows you to store information about the sales territory that is assigned to a
user. This includes information about the territory name, a description, the currency code, and the
sales quota for the territory. The territory object does not have any associated child objects, however,
the territory object is a parent object and is defined in its own WSDL.
Methods Called
Table 99 details the methods called by the territory service, and their names as defined on the
service.
Table 99. Methods Called by Territory Service
“Delete” on page 148 TerritoryDelete
“Insert” on page 149 TerritoryInsert
“InsertOrUpdate” on page 150 TerritoryInsertOrUpdate
Table 99. Methods Called by Territory Service
“QueryPage” on page 151 TerritoryQueryPage
“Update” on page 156 TerritoryUpdate
Fields
All fields on the territory object are filterable. The TerritoryName field is a user key for the territory
object.
Table 100 details the required and read-only fields for the territory object.
Table 100. Required and Read-Only Fields for the Territory Object
Field Name Type
TerritoryName Required
Territory Read-only
Table 101 details the status key for the territory object.
Table 101. Status Key for the Territory Object
Territory CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
TerritoryId
Table 102 details the pick map field for the territory object.
Table 102. Pick Map Field for the Territory Object
ParentTerritoryIntegrationId ParentTerritoryId
ParentTerritoryExternalSystemId ParentTerritoryId
ParentTerritoryId ParentTerritoryId
Table 103 details the list of value fields available for the territory object.
Table 103. Picklists Available for the Territory Object
Field Name LOV Type
ParentTerritoryExternalSystemId PARENT_TERRITORY_ID
ParentTerritoryIntegrationId PARENT_TERRITORY_ID
For more information on the fields exposed through the territory Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the territory
object.
User
The user object allows you to define and record details of all users in the system—for example, name,
position, contact details, manager, and so on. It is different from the Current User object in that it is
not restricted only to the currently logged in user. It enables queries to be run on all users of the
system, and enables an administrator to insert and update a user’s profile. The user object does not
have any child components.
Parent Service
User Group
Methods Called
Table 104 details the methods called by the user service, and their names as defined on the service.
Table 104. Methods Called by User Service
“Insert” on page 149 UserInsert
“InsertOrUpdate” on page 150 UserInsertOrUpdate
“QueryPage” on page 151 UserQueryPage
“Update” on page 156 UserUpdate
Fields
All fields on the user object are filterable.
Table 105 details the required and read-only fields for the user object.
Table 105. Required and Read-Only Fields for the User Object
Field Name Type
FirstName Required
LastName Required
CreatedBy Read-only
LastSignInDateTime Read-only
ManagerFullName Read-only
Table 106 details the status key for the user object.
Table 106. Status Key for the User Object
User EMailAddr
Id
IntegrationId
LastModified
LastModifiedByPersonId
Table 107 details the pick map field for the user object.
Table 107. Pick Map Field for the User Object
Role RoleId
Table 108 provides a list of user key combinations for the user object.
Table 108. User Key Fields on the User Object
Child Components User Key Field Combinations

User UserId
ExternalSystemId
IntegrationId
EmailAddr
For more information on the fields exposed through the user Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the user object.
See Also
Current User
User Group
The User Group object allows you to create groups to which users can be added. Users can only be
a member of one group, and groups can contain many users.
Child Component
User
Methods Called
Table 109 details the methods called by the user group service, and their names as defined on the
service.
Table 109. Methods Called by User Group Service
“Delete” on page 148 UserGroupDelete
“Insert” on page 149 UserGroupInsert
“InsertOrUpdate” on page 150 UserGroupInsertOrUpdate
“QueryPage” on page 151 UserGroupQueryPage
“Update” on page 156 UserGroupUpdate
Fields
Table 110 details the required and read-only fields for the user group object.
Table 110. Required and Read-Only Fields for the User Group Object
User Group Name Required
UserGroupId Read-only
User UserGroupUserId Read-only
UserId Read-only
Alias Read-only
Email Read-only
Role Read-only
Table 111 details the status key for the user group object.
Table 111. Status Key for the User Group Object
UserGroup CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
UserGroupId
UserGroupIntegrationId
UserGroupExternalSystemId
User CreatedBy
CreatedById
CreatedDate
Members_UserId
ModifiedBy
ModifiedById
ModifiedDate
UserIntegrationId
Table 112 details the pick map field for the user group object.
Table 112. Pick Map Field for the User Group Object
User UserIntegrationId UserId
UserExternalSystemId UserId
Table 113 provides a list of the filterable fields for the child components of the user group object, and
a list of user key combinations for each child component. All parent fields on the user group object
are filterable.
Table 113. Filterable Fields and User Key Fields on the Solution Object’s Child Components
User Group All Name
User UserGroupId
UserId
UserIntegrationId
Alias
Email
Role
UserFirstName
UserLastName
For more information on the fields exposed through the user group Web service, go to the Web
Services Administration screen within the OnDemand application and generate the WSDL for the user
group object.
Vehicle
The vehicle object allows you to create and store information about a vehicle, for example, a car, a
truck, a van, and so on, that your company would like to sell to a contact or account. This information
includes the vehicle’s current mileage, the invoice price, the dealership, the make, and so on.
NOTE: To download the Vehicle WSDL, you must be given access to the Vehicle object. If you do not
have access to the Vehicle object, it will not be available to download from the Web Services
access to the Vehicle object, contact your Siebel CRM OnDemand service provider.
Child Component
Contact
Methods Called
Table 114 details the methods called by the vehicle service, and their names as defined on the
service.
Table 114. Methods Called by Vehicle Service
“Delete” on page 148 VehicleDelete
“Insert” on page 149 VehicleInsert
“InsertOrUpdate” on page 150 VehicleInsertOrUpdate
“QueryPage” on page 151 VehicleQueryPage
“Update” on page 156 VehicleUpdate
Fields
Table 115 details the required and read-only fields for the vehicle object.
Table 115. Required and Read-Only Fields for the Vehicle Object
Vehicle VehicleId Read-only
Contact Read-only
ProductType Read-only
SellingDealer Read-only
ServicingDealer Read-only
Contact ContactId Required
ContactExternalSystemId Required
ContactIntegrationId Required
Table 116 details the status key for the vehicle object.
Table 116. Status Key for the Vehicle Object
Vehicle CreatedBy
CreatedById
CreatedDate
ExternalSystemId
IntegrationId
ModifiedBy
ModifiedById
ModifiedDate
VehicleId
Contact ContactId
CreatedBy
CreatedById
CreatedDate
ModifiedBy
ModifiedById
ModifiedDate
Table 117 details the pick map fields for the vehicle object.
Table 117. Pick Map Fields for the Vehicle Object
Vehicle AccountName AccountId
AccountSite AccountId
AccountExternalID AccountId
SellingDealerExternalId SellingDealerId
SellingDealerIntegrationId SellingDealerId
ServicingDealerExternalId ServicingDealerId
ServicingDealerIntegrationId ServicingDealerId
Contact ContactExternalSystemId ContactId
Table 118 provides a list of the filterable fields for the child components of the vehicle object, and a
list of user key combinations for each child component. All parent fields on the vehicle object are
filterable.
Table 118. Filterable Fields and User Key Fields on the Vehicle Object’s Child Components
Vehicle All VehicleId

ExternalSystemId
IntegrationId
ContactExternalSystemId ContactExternalSystemId
ContactFirstName
OnDemand Objects Exposed Through Web Services ■ Child Objects
Table 119 details the list of value fields available for the vehicle object.
Table 119. Picklists Available for the Vehicle Object
Field Name LOV Type
Body AUTO_BODY_STYLE_TYPE
Door AUTO_DOORS_STYLE_TYPE
ExteriorColor AUTO_EXTERIOR
InteriorColor AUTO_INTERIOR
Location AUTO_VEHICLE_LOC
VehicleOwnedBy AUTO_OWNED_BY
Status IMPL_PHASE
UsedNew AUTO_NEW_USED_TYPE
WarrantyType WARR_TYPE
Year YEAR
For more information on the fields exposed through the vehicle Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the vehicle
object.
Child Objects
The following is a list of the child objects that are used in Siebel OnDemand Web Services:
■ “Address” on page 142
■ “Asset” on page 142
■ “Audit Trail” on page 143
■ “Competitor” on page 143
■ “Login History” on page 143
■ “Multiple Contact Roles” on page 144
■ “Note” on page 144
■ “Partner” on page 144
■ “Quota” on page 145
■ “Revenue” on page 145
■ “Related Account” on page 145
■ “Related Contact” on page 145
■ “Team” on page 146
Address
The address object stores information on the different addresses that are associated with accounts
and contacts. It is used to store billing and shipping addresses for accounts. It is also used to store
personal addresses for contacts.
Parent Object
Account
Asset
The asset object stores information on the assets held by your accounts—for example, the products
that an account has purchased. The asset object is used to manage products through their life cycle.
It is also used by your accounts to register products, receive product news and literature, track
warranty agreements, and receive recommendations on scheduled services.
Fields
Table 120 details the list of value fields available for the asset object.
Table 120. Picklists Available for the Asset Object
Field Name LOV Type
Type PRODUCT_TYPE
For more information on the fields exposed through the user Web service, go to the Web Services
Administration screen within the OnDemand application and generate the WSDL for the asset object.
Parent Object
Account
Audit Trail
The audit trail object stores information about how a service request object is modified from the
moment that it created until a solution for the service request has been found. The audit trail object
stores information such as the created and modified dates for the service request, and also the users
that created and updated the service request.
Parent Object
Service Request
Competitor
The competitor object in the Account interface exposes the information on competitors for your
accounts.
Fields
Table 121 details the list of value fields available for the competitor object.
Table 121. Picklists Available for the Competitor Object
Field Name LOV Type
RelationshipRole PARTY_REL_TYPE
ReverseRelationshipRole PARTY_REL_TYPE
For more information on the competitor fields exposed, go to the Web Services Administration screen
within the OnDemand application and generate the WSDL file.
Parent Object
Account
Login History
The login history object stores information about currently logged in user such as the amount of
times that the user has logged in, and the dates and times on which the current user logged in.
Parent Object
Current User
Multiple Contact Roles

The multiple contact roles object stores information on the different roles that a contact can hold
within an account. It stores information on the different types of jobs that one contact can hold within
your organization. For example, the customer relations manager may also have a role within the
sales team to provide valuable feedback the sales representatives.
Parent Objects
Account
Note
The note object stores extra information (as a note) on a parent object. This allows employees who
are working on a particular record to add extra information as they see fit. For example, when talking
to a contact, an employee may notice that the contact is not happy with a service provided. The
employee may record this in a note so that any other employees who talk to the contact are aware
of the contact’s dissatisfaction.
Parent Objects
Account, Campaign, Contact, Opportunity and Service Request
Partner
The partner object in the Account interface exposes the information on partners for your accounts.
Fields
Table 122 details the list of value fields available for the partner object.
Table 122. Picklists Available for the Partner Object
Field Name LOV Type
RelationshipRole PARTY_REL_TYPE
ReverseRelationshipRole PARTY_REL_TYPE
For more information on the partner fields exposed, go to the Web Services Administration screen
within the OnDemand application and generate the WSDL file.
Parent Object
Account
Quota
The quota object stores information about the sales targets of, and sales made by the current user.
Parent Object
Current User
Related Account
The related account object stores information on an account that has a relationship with the parent
account in question. The details of the related account child object are inherited from a particular
account parent object.
Parent Object
Account
Related Contact
The related contact object stores information on an contact that has a relationship with the parent
contact in question. The details of the related contact child object are inherited from a particular
contact parent object.
Parent Object
Contact
Revenue
The revenue object stores monetary information about accounts, contacts and their associated
opportunities. This includes information on the revenue available, expected revenue, and also
information about the products associated with the accounts, contacts and opportunities, and so on.
Parent Object
Account, Contact and Opportunity
Team
The team object stores information on the team that is assigned to a particular account or contact.
In this way, a team of employees can be dedicated to an account or contact, ensuring that the
activities, service requests, leads, and opportunities surrounding that account or contact are always
kept up-to-date and are attended to regularly.
Parent Object
Account and Contact
5 Web Services OnDemand API
Calls
There are a number of methods that can be invoked by the OnDemand objects. For each object, the
methods are defined in the WSDL for that object. Many of the methods described in this chapter can
call all of the objects.
The methods invoked by the OnDemand objects are used to insert, update, and find data within a
specified OnDemand instance. The following sections detail the methods that may be called on the
OnDemand objects. For each of these methods, the description, usage, arguments taken, and return
values are detailed.
This chapter has the following sections:
■ “API Calls”
■ “Service API Calls” on page 157
API Calls
The OnDemand Web Services’ core methods are listed in Table 123. The core methods consist of
those methods that may be called on the OnDemand objects — for example, Account, Contact,
Opportunity, and so on.
Table 123. Web Services OnDemand Core Methods
Method Name Comments
Delete Uses input XML objects to find records in the Siebel OnDemand database
that match specified field values, and then deletes them (in other words,
puts them into the Recycle Bin).
NOTE: To conform with OnDemand’s business logic, be careful about the

order in which objects are deleted. You cannot delete some objects unless
some action is performed on its child objects. For example, you cannot
delete an account unless all its service requests are associated with a
different account.
Insert Inserts a new record to the OnDemand database.
InsertOrUpdate Updates an existing record or inserts a new record if one did not exist for
this instance of the object.
QueryPage Executes a query against a specified list of records, and returns a subset
of the records that match the search criteria set by the method
arguments.
Update Updates the selected record with the new value.
Web Services OnDemand API Calls ■ API Calls
Delete
Removes the record of the specified object from the OnDemand database.
Usage
You use the delete method to remove one or more records of a particular object from an OnDemand
instance.
Table 124 illustrates the behavior of the delete method on child objects related to the parent object
being deleted. For details on deleting a specific child from a parent level object, see “Update” on
page 156.
Table 124. Behavior of Delete Method on Child Objects
Action When Parent Is

Parent Object Child Deleted
Account Activity Delete
Asset None
Competitor None
Contact None
Lead Delete
Note Delete
Opportunity Delete
Partner None
ServiceRequest None
Team None
Campaign Activity Delete
Contact None
Lead Delete
Note Delete
Opportunity Delete
Contact Activity None
Lead Delete
Note Delete
Opportunity None
ServiceRequest None
Lead Activity Delete
Table 124. Behavior of Delete Method on Child Objects
Action When Parent Is

Parent Object Child Deleted
Opportunity Activity Delete
Contact None
Lead Delete
Note Delete
ServiceRequest Activity Delete
AuditTrail None
Note None
Solution Not Specified
Solution ServiceRequest None
Arguments
Table 125 documents the arguments taken by the delete method.
Table 125. Arguments Taken by the Delete Method
Name Description Required Default I/O
ListOf(Object). For The list of object instances to be Yes Not I/O

example, ListOfAccount deleted. applicable
Return Value of the Call

The status key for each of the deleted objects.
See Also
Update.
Insert
Inserts a new record in the OnDemand database.
Usage
You use the insert object to create one or more records of a particular object from an OnDemand
instance. Each of the objects (both child and parent level) provided in the input argument must
provide data in at least one of the user keys for the given object. The user key information is used
to uniquely identify records. If no user key values are provided, or if there is a conflict with the user
keys of an existing record, the insert method will fail, and a SOAP error will be thrown by the API.
When inserting a batch of records, the batch is treated as a single transaction. If one record fails to
insert during a batch insertion, the entire operation is rolled back and no records are inserted.
Arguments
Table 126 documents the arguments taken by the insert method.
Table 126. Arguments Taken by the Insert Method
ListOf(Object). For The list of object instances to be Yes Not I/O

example, ListOfAccount inserted. applicable

The status key for each of the OnDemand objects.
See Also
Update.
InsertOrUpdate
Updates an existing record or inserts a new record if one did not exist for this instance of the object.
Usage
You use the InsertOrUpdate method to update one or more records of a particular object in an
OnDemand instance. Each of the objects (both child and parent level) provided in the input argument
must provide data in at least one of the user keys for the given object. Use the user key information
to uniquely identify records. If no user key values are provided or if there is a conflict with the user
keys of an existing record, the insert method fails, and a SOAP error is thrown by the API.
Use the user key specified for the parent level objects in the input argument to determine whether
to insert each of the parent records, or to update an existing parent record.
Table 127 outlines how the delete method acts upon parent and child objects to create or update an
object instance.
Table 127. Effect of InsetOrUpdate on Parent and Child Objects
Child Exists in Child Exists in

Existing OnDemand and OnDemand but
Method Name New Parent New Child Parent in Input Not in Input
InsertOrUpdate New parent New child Update Update child Child is

parent unchanged
Arguments
Table 128 documents the arguments taken by the InsertOrUpdate method.
Table 128. Arguments Taken by the InsertOrUpdate Method
ListOf(Object). For The object instance to be inserted Yes Not available I/O
example, ListOfAccount or updated.

The status key for each of the inserted or updated objects.
See Also
Update
Insert
QueryPage
Executes a query against a specified list of records, and returns a subset of the records that match
the search criteria set by the method arguments. You can use the QueryPage method in a number
of different ways to return records, which means that there are a number of functions that can be
performed using this method. For example, it is possible to query by example, by template, or by
children. For more information, see “Querying OnDemand Data Using Web Services” on page 153 and
Appendix A, “OnDemand XML API Samples.”
Usage
This method is useful when the search specification retrieves a large number of records at the root
component. To avoid returning one huge set of results, you can specify the number of records to be
returned using the PageSize argument. You can also use the StartRowNum method argument to
dictate which records are to be returned.
Even though the QueryPage method returns a limited number of records, it keeps the data in the
cache, which you can then retrieve by calling the QueryPage method again with a new value for the
StartRowNum method argument.
For all OnDemand object methods, it is possible to query, update, or insert using one operation within
a parent-child relationship. This type of query is called QueryByChildren. The query can be
assembled using parent attributes as well as child attributes. You can query for all children of a
particular parent or set of parents, all parents of a particular child or set of children, or for both
parents and children of a particular set. The QueryByChildren method uses the same expression
notation as QueryByExample, where the expression may appear in either the parent, the child, or
both. These queries are described in Appendix A, “OnDemand XML API Samples.”
NOTE: If you want to include a field to be returned in a query’s results, you must include a blank tag
in the QueryPage input. Effectively, this means that you must set the field’s value to “”, that is, an
empty string.
About OnDemand Query Syntax

Only fields that have nonempty values are interpreted as part of the search specification. Table 129
illustrates how the field values follow the syntax shown. Nonterminal symbols are in italics.
Table 129. Query by Example Syntax
Syntax Type Syntax
conjunction OR
conjunction AND
expression IS NULL
expression operator value
expression ( expression ) conjunction ( expression )
literal literalChar literal
literalChar ''
literalChar {0x00 ... 0xFF} \ '

literalChar literal Œ
operator =
operator ~=
operator <
Table 129. Query by Example Syntax
Syntax Type Syntax
operator <=
operator >
operator >=
operator <>
operator LIKE
operator ~LIKE
value 'literal'
OnDemand Query Syntax Rules

Syntax rules are as follows:
■ Literal data is always enclosed in single quotes.
■ If you want to use a single quote within a literal, you must place another single quote
immediately beside the quote that you want to specify as a literal. In this way, the query
recognizes the quote as a literal and not as an operator. For example, the string ab'c is presented
as ab''c.
■ In order to use the wildcard characters asterisk (*), question mark (?), and backslash (\) in
queries, they must be preceded by the backslash (\) character. For example, if you want to use
the ? wildcard operator in a query, you must precede it with the backslash character as follows:
\?
■ Every expression must start with an operator to avoid ambiguity. There is no default operator.
■ Wildcard characters are treated as such only in the context of the operator LIKE.
■ To find a match for a value that has no value, the IS NULL expression must be specified as the
QBE field's value.
■ The tilde (~) and equal (=) ~= operator denotes a case-insensitive exact search (no wildcards
used), while the ~LIKE operator denotes a case-insensitive wildcard search.
■ A conjugated expression must be enclosed in parentheses to avoid ambiguity. However,

nonconjugated expressions must not be enclosed in parentheses.
Querying OnDemand Data Using Web Services

The QueryPage functions require a list of object instances as input in order to perform a query. This
input parameter is called ListOf(Object). For example, the ContactQueryPage method requires the
ListOfContact parameter. Each ListOf(Object) parameter requires at least one instance of the Object
in order to specify a valid query.
To query an object by a certain field, specify the Query by Example expression that corresponds to
the desired result. For information about Query by Example expression samples, see Table 137.
Querying Multiple Fields

If you want to query multiple fields, Query by Example expressions must be present in each of the
fields. When multiple fields in an object instance have Query by Example expressions, the QueryPage
method result is the intersection of all the Query by Example expressions, or in other words, all of
the Query by Example expressions are combined using the AND operator. This is outlined in “Example
1: Combining Expressions Using the AND Operator.”
Example 1: Combining Expressions Using the AND Operator

The Web service client requires the first name, last name, and job title of all the contacts in
OnDemand that have a job title equal to CEO and a last name equal to Doe. The XML representation
of the ListOfContact object that must be sent in the ContactQueryPage call is as follows:
<ListOfContact>
<Contact>
<JobTitle>= ‘CEO’</JobTitle>
<ContactLastName>='Doe'</ContactLastName>
<ContactFirstName />
</Contact>
</ListOfContact>
Multiple Query by Example Expressions on a Single Field

If you want to apply multiple Query by Example expressions to a single field, you can combine each
Query by Example expression using either the AND or the OR operator. The result is either the
intersection or the union of the object instances respectively.
NOTE: For multiple Query by Example expressions on a single field, each Query by Example
expression must be enclosed in brackets.
Example 2: Combining Multiple Expressions Using the AND Operator

The Web service client requires the first name, last name, and job title of all the contacts that have
been updated between July 28, 2004 6:30am and July 28, 2004 6:45 am.
Send the following XML representation of the ListOfContact object in the ContactQueryPage call:
<ListOfContact>
<Contact>
<JobTitle />
<ContactLastName />
<LastUpdated> (>='07/28/2004 06:30:00') AND (<='07/28/2004 06:45:00')</

LastUpdated >
</Contact>
</ListOfContact>
Example 3: Combining Multiple Expressions Using the OR Operator

The Web service client requires the first name, last name, and job title of all the contacts in
OnDemand that have a last name equal to Doe or Brown.
Send the following XML representation of the ListOfContact object in the ContactQueryPage call:
<ListOfContact>
<Contact>
<JobTitle />
<ContactLastName>(='Doe') OR (=’Brown’)</ContactLastName>
</Contact>
</ListOfContact>
Arguments
Table 130 documents the arguments taken by the QueryPage method.
Table 130. Arguments Taken by the QueryPage Method
ListOf(Object). The list of object instances queried (input), Yes Not I/O
For example, and after query execution, the list of object applicable
ListOfAccount instances returned (output).
PageSize The maximum number of records displayed No 10 I

on a page following a query.
Table 130. Arguments Taken by the QueryPage Method
StartRowNum Indicates the row from which the QueryPage No 0 I

method starts to return records. Use the
StartRowNum parameter to return a set of
records for any given method.
For example, if you want to return records

1-100, you set the StartRowNum parameter
to 1. Then, if you want to return records
101-200, you set StartRowNum to 101, and
run the query again. You continue doing this
until the last page is returned. This way, you
can return all records for a particular query.
UseChildAnd If this parameter is set to TRUE, then the No FALSE I

query result set returns the set of fields that
are common to both parent and child
components. (That is, the query set
returned is the AND combination of parent
and child fields).
If this parameter is set to FALSE (or not set

at all), then the query result set returns the
set of fields that are common to either the
parent component or the child component.
(That is, the query set returned is the OR
combination of parent and child fields).

An object or list of objects of the type on which the method was called.
LastPage: A Boolean value that indicates whether or not the last value in the query set has been
returned.
Update
Updates the selected record with the new value.
Usage
You use the update method to update one or more records of a particular object in an OnDemand
instance. Each of the objects (both child and parent level) provided in the input argument must
provide data in at least one of the user keys for the given object. You use the user key information
to uniquely identify records. If no user key values are provided, or if there is a conflict with the user
keys of an existing record, the insert method will fail, and a SOAP error is thrown by the API.
Web Services OnDemand API Calls ■ Service API Calls
Table 131 outlines how the update method acts upon parent and child objects to update an object
instance.
Table 131. Effect of Update on Parent and Child Objects
Child Exists in Child Exists in

Existing OnDemand and OnDemand but
Method Name New Parent New Child Parent in Input Not in Input
Update Error New child Update Update child Child is removed

parent
Arguments
Table 132 documents the arguments taken by the update method.
Table 132. Arguments Taken by the Update Method
ListOf(Object). For The object instance to be updated. Yes Not I/O

example, ListOfAccount applicable

The updated object.
Service API Calls

The OnDemand Web Services’ service methods are listed in Table 133. The service methods consist
of those methods that are not called on OnDemand objects. Instead they are used to carry out
functions that enable external applications to establish an interface with the OnDemand GUI.
Table 133. Web Services OnDemand Service Methods
Method Name Comments
“GetListOfValues” on Gets a lists of values from external applications and presents them to
page 158 OnDemand end users.
“GetMapping” on Gets a list of the display names of fields for a particular service and their
page 159 associated XML tags.
“SetPasswordAPI” on Sets the passwords of users that use the application.

page 159
GetListOfValues
Gets a list of values from external applications and presents them to OnDemand end users.
Usage
This method is used to enable external applications to present lists of values to end users, typically
in a language-dependent manner.
Because OnDemand Web Services is language-independent, it is the client application’s responsibility

to convert code from language-independent code (LIC) used by OnDemand to language-dependent
values (LDVs) typically used by the external presentation layer.
The returned list of values corresponds to the organization to which the current end user (that is,
the user whose credentials have been passed during the log-in call) belongs.
NOTE: You can use this method for getting the list of values allowed for customized picklist fields—
for example, in querying LOV type OCC_CUST_LOV_ACCOUNT_0 to get a list of values for the field
with XML tag CustomPickList0 in the Account Web Service.
For examples of LOV Service elements, see “LOV Service Element Sample” on page 170.
Arguments
Table 134 documents the arguments taken by the GetListOfValues method.
Table 134. Arguments Taken by the GetListOfValues Method
LOVType List of value types to be queried. Yes Not I

applicable
LanguageCode Code of the language in which No User’s I

language-dependent values are to be Default
returned—for example, ENU, DEU, FRA, Language
ESN, and so on. If not specified, the
default language for the current
session’s end user is used.
ListOfLOV A sequence of LOV elements that Yes Not O

represent individual values and contain applicable
the following subelements:
■ Language
■ LIC (Language Independent Code)
■ Type
■ LDV (Language Dependent Value)

ListOfLOV: A list of values from an external application.
GetMapping
Returns the display names and XML tags of the fields of a named Web service or one of its child
components.
Usage
This method is used to return the display names of all the fields in a particular Web service. It also
returns the XML tags for each field. It, therefore, displays the mappings between the display names
of fields and their XML tags.
This method can be used on all Web services and on all of their child components.
Arguments
Table 135 documents the arguments taken by the GetListOfValues method.
Table 135. Arguments Taken by the GetMapping Method
ObjectName The name of the object for which you Yes NA I

wish to return a list of mappings.

A list of the display names for fields and their associated XML mappings.
SetPasswordAPI
Allows the system administrator to set the passwords of users that use the application.
Usage
This method is used to enable external applications to synchronize user passwords. For security
reasons the password API is not available by default. If a customer wishes to use SetPasswordAPI,
they can call Customer Care to have the functionality enabled.
The API allows for the setting of passwords for one or more users at the same time. For each
password that is updated, a corresponding user Audit Trail record is created. A user with the ability
to set passwords does not have the ability to update the password of another user that has the ability
to set passwords.
Table 136 details the arguments taken by SetPasswordAPI.
Table 136. Arguments Taken by SetPasswordAPI
Field Name Type
UserId Read-only
UserExternalId Read-only
UserIntegrationID Read-only
UserEmail Read-only
Password Create/Read/Update/Delete
A OnDemand XML API Samples
This appendix displays samples of XML code generated by OnDemand, and it contains the following
sections:
■ “Query by Example Expression Samples”
■ “Query by Template Samples” on page 164
■ “Query by Children Samples” on page 165
■ “LOV Service Element Sample” on page 170
Query by Example Expression Samples

The examples in this section cover the corner cases of quote and wildcard escaping. Assume that a
table in the OnDemand database contains the following values for a particular column that is being
queried by example:
abc
abcd
'abc'
= 'abc'
abc?d
abc*d
aBc*D
abcd
abc*d
abc\d
abc\*d
abc\\*d
abc\d
abc\*'d
abc\?"d
abc\*"d
abc\*'"d
(NULL value)
OnDemand XML API Samples ■ Query by Example Expression Samples
Table 137 specifies the returned record sets for various values of each Query by Example field value
that maps to the preceding list.
Table 137. Returned Record Sets
QBE Field Value Returned Record Set Comments
abc N/A An unquoted value without an explicit operator

is invalid input.
'abc' N/A A quoted value without an explicit operator is

invalid input.
= '''abc ''''abc'
= "'abc'" N/A Double quotes are not allowed by OnDemand

Query Validator. Consequently, this example
returns an error message.
= 'abc 'abc
= '= ''abc '''= 'abc'
= '= 'abc'' N/A The caller is responsible for correctly

formatting quotes in Query* methods. This
example does not have correctly formatted
quotes, so it results in an error.
= 'abc?d 'abc?d
= 'abc\?d 'abc?d
LIKE 'abc\?d 'abc?d
LIKE 'abc?d 'abc?d

abc*d
abc\d
~LIKE 'abc?d 'abc?d
aBc*D
abc*d
abc\d
= 'abc*d' abc*d An wildcard character that has not been
formatted with quotes is treated as if it were
formatted with quotes.
= 'abc\*d 'abc*d
= 'abc\\*d 'abc\*d
OnDemand XML API Samples ■ Query by Example Expression Samples
Table 137. Returned Record Sets
QBE Field Value Returned Record Set Comments
LIKE 'abc\\*d 'abc\d

abc\*d
abc\\*d
abc\d
abc\*'d
abc\?"d
abc\*"d
abc\*'"d
= 'abc\\\*"d 'abc\*"d
= 'abc\\?"d 'abc\?"d
= 'abc\\\?"d 'abc\*"d
LIKE 'abc\\?"d 'abc\?"d

abc\*"d
LIKE 'abc\\\?"d 'abc\?"d
LIKE 'abc\\*"d 'abc\?"d

abc\*"d
abc\*'"d
LIKE 'abc\\\*"d 'abc\*"d
= 'abc\\\*''d 'abc\*'d
~ LIKE 'abc*\d 'aBc*D

abc*d
abcd
abc*d
LIKE 'abc*\d 'abc*d
abcd
abc*d
(empty field) N/A An empty field value does not influence the
search specification in Query by Template.
IS NULL (empty field)

(( > 'abc*' )
AND ( < 'abcd' ))
OR (~= 'abc*d') abc*d
aBc*D
abc*d
NOT LIKE 'abc?d' N/A OnDemand Query Validator does not support
the NOT operator, so this query returns an
error.
> 'abc' BUT < 'abcd' N/A BUT is not a valid conjunction. Consequently,
this query returns an error.
OnDemand XML API Samples ■ Query by Template Samples
Query by Template Samples

The OnDemand Export API has Query by Template semantics. This means that only components and
fields that are present in the input parameter are present in the output parameter.
Query by Template Example 1

The following is an example of an input integration object instance:
<ListOfAccount>
<Account>
<LastUpdated>>= '10/13/2003 03:25:32'</LastUpdated>
<Name />
<Location>IS NULL</Location>
</Account
</ListOfAccount>
The search specification that the system applies to the Account BusComp is as
follows:
[LastUpdated] >= '10/13/2003 03:25:32' AND [Location] IS NULL.
The following shows an example of the XML returned:
<ListOfAccount>
<Account>
<LastUpdated>10/14/2003 04:25:32</LastUpdated>
<Name>IBM</Name>
<Location></Location>
</Account>
<Account>
<LastUpdated>10/13/2003 03:25:36 PM</LastUpdated>
<Name>Siebel</Name>
</Account>
</ListOfAccount>
OnDemand XML API Samples ■ Query by Children Samples
Query by Template Example 2

The following is an example of an input integration object instance:
<ListOfAccount>
<Account>
<LastUpdated/>
<Name>LIKE 'Sie*'<Name/>
<Location>= 'San Mateo'</Location>
</Account>
</ListOfAccount>
The system applies the search specification as follows:
[Name] LIKE 'Sie*' AND [Location] = 'San Mateo'
The following is an example of the XML returned:
<ListOfAccount>
<Account>
<LastUpdated>10/19/2003 09:22:33 AM</LastUpdated>
<Name>Siebel Systems, Inc.</Name>
<Location>San Mateo</Location>
</Account>
<Account>
<LastUpdated>8/22/2003 03:25:36 PM</LastUpdated>
<Name>Siemens</Name>
<Location>San Mateo</Location>
</Account>
</ListOfAccount>
Query by Children Samples

The examples in this section illustrate the semantics of queries that include search specifications on
child components.
Query by Children Example 1

This example illustrates data synchronization through periodic exports based on the time of the last
update:
<ListOfAccount>
<Account>
<Name></Name>
<LastUpdated>(> '05/12/02 10:00:03 PM') AND (<= '05/18/02 10:02:22 PM')</

LastUpdated>
<ListOfContact>
<Contact>
FirstName><FirstName>
<LastName></Lastname>
<LastUpdated>(> '05/12/02 10:00:03 PM') AND (<= '05/18/02 10:02:22

PM')</LastUpdated>
</Contact>
</ListOfContact>
<ListOfBusinessAddress>
<BusinessAddress>
<Address/>
<City/><State/>
<ZipCode/>
<LastUpdated>(> '05/12/02 10:00:03 PM') AND (<= '05/18/02 10:02:22 PM')</

LastUpdated>
<BusinessAddress>
</ListOfBusinessAddress>
</Account>
</ListOfAccount>
Using a formal search specification language, the system interprets this query as follows:
(([Account_LastUpdated] > '05/12/02 10:00:03 PM')
AND
([Account_LastUpdated] <= '05/18/02 10:02:22 PM')
OR
EXISTS
([Contact_LastUpdated] >= '05/12/02 10:00:03 PM')
AND
([Contact_LastUpdated] <= '05/18/02 10:02:22 PM')
OR
EXISTS
([BusinessAddress_LastUpdated] > '05/12/02 10:00:03 PM')
AND
([BusinessAddress_LastUpdated] <= '05/18/02 10:02:22 PM')
This tells the system to find all accounts that have met one of the following conditions between 05/
12/02 10:00:03 PM and 05/18/02 10:02:22 PM in the current user's time zone that have:
■ Been updated
■ Been associated with at least one new contact
■ Changed or added at least one business address

This example shows how to query to find all child opportunities associated with a contact:
<ListOfOpportunity>
<Opportunity>
<Description/>
<Revenue></Revenue>
<ListOfContact>
<Contact>
<Id>(= '12-12345') OR (= '12-54321')</Id>
<FirstName></FirstName>
<LastName></Lastname>
</Contact>
</ListOfContact>
</Opportunity>
</ListOfOpportunity>
Using a formal search specification language, the system interprets this query as follows:
EXISTS( [Contact_Id]='12-12345' OR [Contact_Id]='12-54321' )
This tells the system to find all opportunities that are associated either with a contact whose Id is
12-12345, or with a contact whose Id is 12-54321.

This example illustrates the interpretation of peer inter-component and intra-component
expressions, and the fact that the default operator for text fields is LIKE:
<ListOfAccount>
<Account>
<Name></Name>
<LastUpdated>> 05/12/02 10:00:03 PM</LastUpdated>
<ListOfContact>
<Contact>
<FirstName>= 'Sanjin'<FirstName>
<LastName>= 'Tulac'</Lastname>
<MiddleName />
</Contact>
<Contact>
<FirstName>LIKE 'Alex*'<FirstName>
<LastName>LIKE 'Warsha*'</Lastname>
</Contact>
</ListOfContact>
<ListOfOpportunity>
<Opportunity>
<Description/>
<Revenue>>= '10000'</Revenue>
</Opportunity>
</ListOfOpportunity>
</Account>
</ListOfAccount>
The system interprets this input to the QueryPage method as the following search specification:
[Account_LastUpdated] >= '05/12/02 10:00:03 PM'
OR
EXISTS
([Contact_FirstName]='Sanjin') AND ([Contact_LastName]='Tulac')
OR
([Contact_FirstName]LIKE 'Alex*') AND [Contact_LastName]LIKE 'Warsha*')
OR
EXISTS
[Opportunity_Revenue] >= '10000'
This tells the system to find all accounts that meet one of the following conditions:
■ Have been updated since 05/12/02 10:00:03 PM in current user's time zone
■ Are associated with a contact whose first name is Sanjin and whose last name is Tulac
■ Are associated with a contact whose first name starts with Alex and whose last name starts with
Warsha
■ Have an associated opportunity whose revenue is estimated at more than 10000 units of
currency
OnDemand XML API Samples ■ LOV Service Element Sample
LOV Service Element Sample

The following is a sample of the ListOfLOV XML element:
<ListOfLOV>
<LOV>
<Language>ENU</Language>
<LIC>Competitor</LIC>
<Type>ACCOUNT_TYPE</Type>
<LDV>Competitor</LDV>
</LOV>
<LOV>
<LIC>Customer</LIC>
<LDV>Customer</LDV>
</LOV>
<LOV>
<LIC>Partner</LIC>
<LDV>Partner</LDV>
</LOV>
</ListOfLOV>
Index
A C
access C# code sample 30
locale-dependent access 18 campaign object
Account interface about 54
competitor object 143 child components 55
partner object 144 fields 55
account object filterable fields 58
about 34 list of values 60
child components 34 methods 55
fields 35 parents 55
fields, do not use 48 pick map field 58
filterable fields 41 read-only fields 55
methods 34 required fields 55
pick map fields 40 status key 56
picklists 47 child components
read-only fields 35 account 34
required fields 35 activity 49
status key 36 campaign 55
activity object contact 60, 98
about 48 current user 73
child components 49 CustomObject1 75
fields 49 CustomObject2 83
filterable fields 53 household 93
list of values 54 opportunity 104, 118
methods 49 portfolio 113
parents 49 service request 122
pick map fields 52 solution 127
read-only fields 49 user group 135
required fields 49 vehicle 137
status key 50 child objects
usage 48 asset 142
user key fields 53 audit trail 143
API calls competitor 143
core methods 147 login history 143
Delete method 148 multiple contact roles 144
GetListOfValues 158 note 144
GetMapping 159 partner 144
Insert method 149 quota 145
InsertOrUpdate method 150 related account 145
QueryPage method 151 related contact 145
Service API calls 157 revenue 145
SetPasswordAPI 159 team 146
Update method 156 client integrations
asset child object 142 examples 10
audit fields 17 code samples
audit trail object 143 C# code sample 30
Java code sample 26
Index ■ D
logging in/off 23 user keys 81, 89

VB code sample 24 CustomObject2 object
company-specific WSDL 17 about 83
competitor object child components 83
about 143 fields 84
fields 143 list of values 91
contact object methods 83
about 60 pick map 87
child components 60, 98 read-only fields 84
fields 61 required fields 84
filterable fields 67 status key 85
list of values 72
methods 61 D
objects not to use 73 Date and Time fields 18
parents 60 dealer object
pick map 66 about 91
read-only fields 61 fields 92
required fields 61 methods 91
status key 62 pick map field 92
core methods read-only fields 92
Delete method 148 required fields 92
GetListOfValues 158 status key 92
GetMapping 159 Delete method
Insert method 149 arguments 149
InsertOrUpdate method 150 usage 148
list of 147
QueryPage method 151
Service API calls 157 F
SetPasswordAPI 159 features, what’s new 7
Update method 156 field types
core technologies custom fields 17
about 9 supported 18
Currency and Number fields 18 fields
current user object audit 17
about 73 custom fields 17
child components 73 read-only, account object 35
fields 74 read-only, activity object 49
filterable fields 74 read-only, campaign object 55
methods 73 read-only, contact object 61
read-only fields 74 read-only, current user object 74
required fields 74 read-only, CustomObject1 object 75
custom fields 17 read-only, CustomObject2 object 84
customization-specific WSDL 17 read-only, dealer object 92
CustomObject1 object read-only, household object 95
about 75 read-only, lead object 98
child components 75 read-only, opportunity object 105
fields 75 read-only, portfolio object 114
filterable fields 81, 89 read-only, product category object 121
list of values 82 read-only, product object 118
methods 75 read-only, service request object 123
pick map 79 read-only, solution object 128
read-only fields 75 read-only, territory object 131
required fields 75 read-only, user group object 135
status key 77 read-only, user object 133
Index ■ G
read-only, vehicle object 138 usage 150

required, account object 35 integration tag, viewing 17
required, activity object 49 integrations
required, campaign object 55 client integration examples 10
required, contact object 61 XML API session, integration requests 21
required, current user object 74
required, CustomObject1 object 75 J
required, CustomObject2 object 84 Java code sample 26
required, dealer object 92
required, household object 95
required, lead object 98 K
required, opportunity object 105 keys
required, product category object 121 status key, about 16
required, product object 118 status key, account object 36
required, service request object 123 status key, activity object 50
required, solution object 128 status key, campaign object 56
required, territory object 131 status key, contact object 62
required, user group object 135 status key, CustomObject1 object 77
required, user object 133 status key, CustomObject2 object 85
required, vehicle object 138 status key, dealer object 92
status key, household object 96
status key, lead object 99
G status key, opportunity object 107
generating customized WSDL 17 status key, product category object 121
GetListOfValues 158 status key, product object 115, 119
GetListOfValues method status key, service request object 124
call return value 159 status key, solution object 128
GetMapping 159 status key, territory object 131
GetMapping method status key, user group object 136
arguments 158 status key, user object 134
call return value 159 status key, vehicle object 139
user key, about 15
H user key, product category object 122
household object user key, product object 119
about 93 user key, user object 134
child components 93
fields 95 L
filterable fields 97 lead object
list of values 93, 97 about 98
methods 94 fields 98
pick map field 97 filterable fields 101
read-only fields 95 methods 98
required fields 95 parents 98
status key 96 pick map fields 100
picklists 101
I read-only fields 98
Insert method required fields 98
arguments 150 status key 99
call return value 150 locale-dependent access 18
usage 149 login history child object 143
InsertOrUpdate method LOV object
arguments 151 about 102
call return value 151 methods 104
parent and child objects, effect on 151 LOV service element sample 170
Index ■ M
M methods 15
methods parent and child relationships, about 14
OnDemand objects, called by 15 pick maps 16
parent and child objects, behavior of 15 status keys 16
methods called by user keys 15
account 34 XML API Reliability 12
activity 49 XML API Security 11
campaign 55 opportunity object
contact 61 about 104
current user 73 child components 104, 118
CustomObject1 75 fields 105
CustomObject2 83 filterable fields 110
dealer 91 list of value fields 113
household 94 methods 105
lead 98 parents 104
LOV 104 pick map field 109
opportunity 105 read-only fields 105
portfolio 114 required fields 105
product 118 status key 107
product category 120
service request 123 P
solution 127 parent and child objects
territory 130 about and list of 12
user 133 InsertOrUpdate method, effect on 151
user group 135 methods, behavior of 15
vehicle 138 relationships, about 14
multiple contact roles child object 144 Update method, effect of 157
parent objects
N account 34
new features 7 activity 48
note child object 144 campaign object 54
Number and Currency fields 18 contact object 60
current user 73
dealer 91
O household object 93
objects lead 98
OnDemand objects, methods called by 15 list of 33
OnDemand parent and child objects 12 LOV 102
parent and child objects, behavior of opportunity 104
methods 15 portfolio 113
parent and child relationships, about 14 product 117
pick maps 16 product category 120
status keys 16 service request 122
user keys 15 solution 127
objects, exposed territory 130
See parent objects; child objects user 132
OnDemand user group 135
custom fields 17 vehicle 137
integration tag 17 parent services
OnDemand Web Services 10 activity 49
communication with (figure) 9 campaign 55
OnDemand objects, methods called by 15 contact 60
OnDemand parent and child objects 12 lead 98
parent and child objects, behavior of
Index ■ Q
opportunity 104 required fields 118

product 118 status key 115, 119
service request 122 user keys 119
solution 127
user 132 Q
partner object query by children samples
about 144 example 1 165
fields 144 example 2 167
pick map example 3 168
account object 40 query by example expression samples 161
activity object 52 query by template samples
campaign object 58 example 1 164
contact CustomObject1 79 example 2 165
contact CustomObject2 87 QueryPage method
contact object 66 about 151
dealer object 92 arguments 155
household object 97 call return value 156
lead object pick map fields 100 OnDemand query syntax, about 152
OnDemand pick maps, about 16 querying data using Web Services 153
opportunity object 109 usage 152
portfolio object 116 quota object 145
product category object 122
product object 119
service request object 125 R
user group object 136 read-only fields
user object 132, 134 account object 35
vehicle object 140 activity object 49
portfolio object campaign object 55
about 113 contact object 61
child components 113 current user object 74
fields 114 CustomObject1 object 75
filterable fields 116 CustomObject2 object 84
list of values 117 dealer object 92
methods 114 household object 95
pick map fields 116 lead object 98
read-only fields 114 opportunity object 105
user key fields 116 portfolio object 114
product category object product category object 121
about 120 product object 118
fields 121 service request object 123
methods 120 solution object 128
pick map field 122 territory object 131
read-only fields 121 user group object 135
required fields 121 user object 133
status key 121 vehicle object 138
user keys 122 related account object 145
product object related contact object 145
about 117 release, what’s new 7
fields 118 reliability
methods 118 XML API Reliability 12
parents 118 required fields
pick map field 119 account object 35
picklists 119 activity object 49
read-only fields 118 campaign object 55
Index ■ S
contact object 61 OnDemand Web Services 10

current user object 74 solution object
CustomObject1 object 75 about 127
CustomObject2 object 84 child components 127
dealer object 92 fields 128
household object 95 filterable fields 129
lead object 98 list of value fields 130
opportunity object 105 methods 127
product category object 121 parents 127
product object 118 read-only fields 128
service request object 123 required fields 128
solution object 128 status key 128
territory object 131 status key
user group object 135 about 16
user object 133 account object 36
vehicle object 138 activity object 50
revenue object 145 campaign object 56
contact object 62
S CustomObject1 object 77
security CustomObject2 object 85
XML API Security 11 dealer object 92
Service API calls household object 96
core methods 157 lead object 99
GetListOfValues 158 opportunity object 107
GetMapping 159 product category object 121
SetPasswordAPI 159 product object 115, 119
service request object service request object 124
about 122 solution object 128
child components 122 territory object 131
fields 123 user group object 136
filterable fields 126 user object 134
methods 123 vehicle object 139
parents 122
pick map 125 T
picklists 126 team object 146
read-only fields 123 territory object
required fields 123 about 130
status key 124 fields 131
SetPasswordAPI 159 methods 130
setting up picklists 132
C# code sample 30 read-only fields 131
Java code sample 26 required fields 131
logging in/off code samples 23 status key 131
process of 19 Time and Date fields 18
VB code sample 24
XML API session limits 22 U
XML API session, establishing and Update method
managing 19 arguments 157
XML API session, integration requests 21 call return value 157
XML API session, logging in 20 parent and child objects, effect of 157
XML API session, logging off 21 usage 156
Siebel OnDemand Web Services Toolkit user group object
about 9 about 135
Index ■ V
child components 135 read-only fields 138

fields 135, 138 required fields 138
filterable fields 137 status key 139
methods 135
pick map field 136 W
read-only fields 135 Web services
required fields 135 custom fields 17
status key 136 integration tag 17
user keys Web Services Toolkit
about 15 See Siebel OnDemand Web Services Toolkit
product category object 122 WSDL, generating company-specific 17
product object 119
user object 134
user object X
about 132 XML API Reliability 12
fields 133 XML API samples
methods 133 LOV service element sample 170
parents 132 query by children samples 165
pick map field 132, 134 query by example expression samples 161
read-only fields 133 query by template samples 164
required fields 133 XML API Security 11
status key 134 XML API session
user keys 134 establishing and managing 19
integration requests 21
logging in 20
V logging off 21
VB code sample 24 maximum objects in Web Services
vehicle object request 23
about 137 maximum records returned 23
child components 137 number of sessions limit 22
filterable fields 140 request rate limit 22
methods 138 request size limit 23
pick map field 140 session timeouts 23
picklists 141
Index ■ X

OnDemand Web Services

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

OnDemand Web Services

Uploaded by

Copyright:

Available Formats

CRM OnDemand

Siebel Web Services OnDemand

Siebel Systems, Inc. considers information included in this

Siebel Web Services OnDemand Guide 1

Chapter 1: What’s New in This Release

Chapter 2: Overview of Web Services OnDemand

Chapter 3: Getting Started with Web Services

Chapter 4: OnDemand Objects Exposed Through Web

Chapter 5: Web Services OnDemand API Calls

Appendix A: OnDemand XML API Samples

What’s New in Siebel Web Services OnDemand Guide, Version 5

■ “About Web Services”

■ “Web Services and the OnDemand Objects” on page 12

■ “Field Types Supported by OnDemand” on page 18

About Web Services

Web Services Core Technologies

For more information on Web services technologies, see http://www.w3.org/2002/ws.

Siebel OnDemand Web Services Toolkit

Figure 1. How Web Services Communicate with OnDemand

OnDemand Web Services

Some common examples of client integrations include the following:

XML API Security

■ Inactive sessions are closed automatically after a period of inactivity.

XML API Reliability

Web Services and the OnDemand

Table 2. OnDemand Objects—Parent Object Denoted by P

“Campaign” on Provides a mechanism for marketing products and services to customers

“CustomObject1” on Exposes the functionality of the CustomObject1 OnDemand object to

“CustomObject2” on Exposes the functionality of the CustomObject2 OnDemand object to

“Dealer” on page 91 Stores information about dealerships in the automotive industry.

Table 2. OnDemand Objects—Parent Object Denoted by P

“Opportunity” on Stores information on a potential revenue-generating event and is

“Service Request” on Stores information on requests made by customers of your organization.

“User Group” on Stores information about groups of users.

“Competitor” on Stores information on the competitor.

“Partner” on page 144 Stores information on the partner.

Table 2. OnDemand Objects—Parent Object Denoted by P

About Parent-Child Relationships

Behavior of Methods on Parent and Child Objects

Table 3. Effect of Methods on Parent and Child Objects

Existing Existing Missing

Delete Error Error Removes Error Error

InsertOrUpdate New parent New child Update Update child Child is

Update Error New child Update Update child Child is

Methods Called by the OnDemand Objects

OnDemand User Keys

OnDemand Status Keys

OnDemand Pick Maps

Table 4. Audit Fields for the OnDemand Objects

Field Name Description

“<Creator Full Name>, <CreatedDate>”

CreatedById The Row ID of the user that created the record.

CreatedDate The DateTime stamp of when the record was created.

“<Modified By Full Name>, <ModifiedDate>”

Web Services OnDemand and Custom Fields

To view or modify integration tag information for an object

The integration tag information is displayed for you to view or modify.

To generate a WSDL file that is specific to your company’s customization

2 Select the required object, and click Download.

An object’s WSDL that is specific to your company’s customization is downloaded.

Field Types Supported by OnDemand

■ Boolean fields have value Y for true or N for false.

■ Most other fields can be treated as ordinary text.