U.S. patent application number 13/445662 was filed with the patent office on 2013-01-03 for computer implemented systems and methods for visualizing organizational connections.
This patent application is currently assigned to SALESFORCE.COM, INC.. Invention is credited to Tyler A. Ziemann.
Application Number | 20130002676 13/445662 |
Document ID | / |
Family ID | 47390182 |
Filed Date | 2013-01-03 |
United States Patent
Application |
20130002676 |
Kind Code |
A1 |
Ziemann; Tyler A. |
January 3, 2013 |
COMPUTER IMPLEMENTED SYSTEMS AND METHODS FOR VISUALIZING
ORGANIZATIONAL CONNECTIONS
Abstract
Disclosed are systems, apparatus, methods and computer-readable
media for updating and visualizing information stored in a database
system over a network. In some implementations, a request to
generate a graphical representation of an organizational chart
associated with an organization is received. In various
implementations, a first individual to include in the
organizational chart is identified. Relationship information
associated with the first individual is identified, where the
relationship information identifies hierarchical relationships
between the first individual and a plurality of second individuals
associated with the organization. In various implementations, the
organizational chart is generated based on the first individual and
the relationship information, where the organizational chart
identifies the first and second individuals and the hierarchical
relationships. In some instances, a graphical representation of the
organizational chart capable of being displayed at a user interface
of a display device is generated.
Inventors: |
Ziemann; Tyler A.; (San
Francisco, CA) |
Assignee: |
SALESFORCE.COM, INC.
San Francisco
CA
|
Family ID: |
47390182 |
Appl. No.: |
13/445662 |
Filed: |
April 12, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61502053 |
Jun 28, 2011 |
|
|
|
Current U.S.
Class: |
345/440 |
Current CPC
Class: |
G06T 11/20 20130101 |
Class at
Publication: |
345/440 |
International
Class: |
G06T 11/20 20060101
G06T011/20 |
Claims
1. A computer implemented method comprising: receiving a request to
generate a graphical representation of an organizational chart
associated with an organization; identifying a first individual to
include in the organizational chart; identifying relationship
information associated with the first individual, the relationship
information identifying hierarchical relationships between the
first individual and a plurality of second individuals associated
with the organization; and generating the organizational chart
based on the first individual and the relationship information, the
organizational chart identifying the first and second individuals
and the hierarchical relationships, a graphical representation of
the organizational chart capable of being displayed at a user
interface of a display device.
2. The computer implemented method of claim 1, wherein the
relationship information includes shared contact data aggregated
from a plurality of entities and stored in a first virtual portion
of a database system, the first virtual portion of the database
system accessible by the plurality of entities.
3. The computer implemented method of claim 2 further comprising:
storing the organizational chart in a second virtual portion of the
database system, the second virtual portion of the database system
storing private contact data accessible by a user of a database
service.
4. The computer implemented method of claim 3, wherein the database
system comprises one or more multitenant databases accessible via
an on-demand computing services environment.
5. The computer implemented method of claim 1 further comprising:
identifying structural information of the organization.
6. The computer implemented method of claim 5, wherein the
structural information of the organization identifies at least a
portion of the hierarchical relationships as being between
divisions included in the organization.
7. The computer implemented method of claim 1, wherein the
relationship information includes biographical information
associated with one or more of the first and second
individuals.
8. The computer implemented method of claim 1, further comprising:
determining at least a portion of the relationship information
based on a role associated with the first individual, the role
indicated by one or more actions between the first individual and
one or more of the second individuals.
9. The computer implemented method of claim 8, wherein the role is
selected from a group consisting of: a decision maker, an
influencer, and a gate keeper.
10. The computer implemented method of claim 8, wherein the role is
indicated by shared contact data aggregated from a plurality of
entities and stored in a virtual portion of a database system, the
virtual portion of the database system accessible by the plurality
of entities.
11. The computer implemented method of claim 1, wherein the first
individual identified to include in the organizational chart is
identified in a previously generated organizational chart.
12. The computer implemented method of claim 1, wherein the first
individual is identified based on an input received by a database
service provider from a user.
13. A system comprising: a database system including one or more
tables configured to store relationship information; and one or
more servers configured to: receive a request to generate a
graphical representation of an organizational chart associated with
an organization; identify a first individual to include in the
organizational chart; identify relationship information associated
with the first individual, the relationship information identifying
hierarchical relationships between the first individual and a
plurality of second individuals associated with the organization;
and generate the organizational chart based on the first individual
and the relationship information, the organizational chart
identifying the first and second individuals and the hierarchical
relationships, a graphical representation of the organizational
chart capable of being displayed at a user interface of a display
device.
14. The system of claim 13, wherein the relationship information
includes shared contact data aggregated from a plurality of
entities and stored in a first virtual portion of a database
system, the first virtual portion of the database system accessible
by the plurality of entities.
15. The system of claim 14, wherein the one or more servers are
further configured to: store the organizational chart in a second
virtual portion of the database system, the second virtual portion
of the database system storing private contact data accessible by a
user of a database service.
16. The system of claim 13, wherein the one or more servers are
further configured to: identify structural information of the
organization.
17. The system of claim 16, wherein the structural information of
the organization identifies at least a portion of the hierarchical
relationships as being between divisions included in the
organization.
18. The system of claim 13, wherein the relationship information
includes biographical information associated with one or more of
the first and second individuals.
19. The system of claim 13, wherein at least a portion of the
relationship information is determined based on a role associated
with the first individual, the role indicated by one or more
actions between the first individual and one or more of the second
individuals.
20. The system of claim 19, wherein the role is selected from a
group consisting of: a decision maker, an influencer, and a gate
keeper.
21. The system of claim 19, wherein the role is indicated by shared
contact data aggregated from a plurality of entities and stored in
a virtual portion of a database system, the virtual portion of the
database system accessible by the plurality of entities.
22. The system of claim 13, wherein the first individual identified
to include in the organizational chart is identified in a
previously generated organizational chart.
23. The system of claim 13, wherein the first individual is
identified based on an input received by a database service
provider from a user.
24. One or more computer-readable storage media having instructions
stored therein for performing a method, the method comprising:
receiving a request to generate a graphical representation of an
organizational chart associated with an organization; identifying a
first individual to include in the organizational chart;
identifying relationship information associated with the first
individual, the relationship information identifying hierarchical
relationships between the first individual and a plurality of
second individuals associated with the organization; and generating
the organizational chart based on the first individual and the
relationship information, the organizational chart identifying the
first and second individuals and the hierarchical relationships, a
graphical representation of the organizational chart capable of
being displayed at a user interface of a display device.
25. The one or more computer-readable storage media of claim 24,
wherein the relationship information includes shared contact data
aggregated from a plurality of entities and stored in a first
virtual portion of a database system, the first virtual portion of
the database system accessible by the plurality of entities.
26. The one or more computer-readable storage media of claim 25,
the method further comprising: storing the organizational chart in
a second virtual portion of the database system, the second virtual
portion of the database system storing private contact data
accessible by a user of a database service.
27. The one or more computer-readable storage media of claim 24,
the method further comprising: identifying structural information
of the organization.
28. The one or more computer-readable storage media of claim 24,
wherein the relationship information includes biographical
information associated with one or more of the first and second
individuals.
29. The one or more computer-readable storage media of claim 24,
wherein the at least a portion of the relationship information is
determined based on a role associated with the first individual,
the role indicated by one or more actions between the first
individual and one or more of the second individuals included in
organization.
30. The one or more computer-readable storage media of claim 24,
wherein the first individual is identified based on an input
received by a database service provider from a user.
Description
PRIORITY AND RELATED APPLICATION DATA
[0001] This application claims priority to co-pending and commonly
assigned U.S. Provisional Patent Application No. 61/502,053, titled
"Systems and Methods for Providing a Mobile Social Enterprise
Interface", by Tyler Ziemann, filed on Jun. 28, 2011 (Attorney
Docket No. 646PROV), which is hereby incorporated by reference in
its entirety and for all purposes.
COPYRIGHT NOTICE
[0002] A portion of the disclosure of this patent document contains
material, which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent file or records, but otherwise
reserves all copyright rights whatsoever.
TECHNICAL FIELD
[0003] The present application relates generally to providing
on-demand services in a network using a database system and, more
specifically, to techniques for updating and visualizing
information stored in the database system over the network.
BACKGROUND
[0004] Organizations typically employ many different types of
software and computing technologies to meet their computing needs.
However, installing and maintaining software on an organization's
own computer systems may involve one or more drawbacks. For
example, when software must be installed on computer systems within
the organization, the installation process often requires
significant time commitments, since organization personnel may need
to separately access each computer. Once installed, the maintenance
of such software typically requires significant additional
resources. Each installation of the software may need to be
separately monitored, upgraded, and/or maintained. Further,
organization personnel may need to protect each installed piece of
software against viruses and other malevolent code. Given the
difficulties in updating and maintaining software installed on many
different computer systems, it is common for software to become
outdated. Also, the organization will likely need to ensure that
the various software programs installed on each computer system are
compatible. Compatibility problems are compounded by frequent
upgrading, which may result in different versions of the same
software being used at different computer systems in the same
organization.
[0005] Accordingly, organizations increasingly prefer to use
on-demand services accessible via the Internet rather than software
installed on in-house computer systems. On-demand services, often
termed "cloud computing" services, take advantage of increased
network speeds and decreased network latency to provide shared
resources, software, and information to computers and other devices
upon request. Cloud computing typically involves over-the-Internet
provision of dynamically scalable and often virtualized resources.
Technological details can be abstracted from the users, who no
longer have need for expertise in, or control over, the technology
infrastructure "in the cloud" that supports them.
BRIEF DESCRIPTION OF THE DRAWINGS
[0006] The included drawings are for illustrative purposes and
serve only to provide examples of possible structures and process
operations for the disclosed inventive systems, apparatus, and
methods for visualizing organizational connections. These drawings
in no way limit any changes in form and detail that may be made by
one skilled in the art without departing from the spirit and scope
of the disclosed implementations.
[0007] FIG. 1 shows a flowchart of an example of a shared contact
data maintenance method 100, performed in accordance with some
implementations.
[0008] FIG. 2 shows a flowchart of an example of a contact data
search method 200, performed in accordance with some
implementations.
[0009] FIG. 3 shows a flowchart of an example of a contact data
reconciliation method 300, performed in accordance with some
implementations.
[0010] FIG. 4 shows a flowchart of an example of an organization
chart construction method 400, performed in accordance with some
implementations.
[0011] FIG. 5 shows a flowchart of another example of an
organization chart construction method 500, performed in accordance
with some implementations.
[0012] FIG. 6 illustrates an example of an image 600 of a user
interface displaying identified shared contact data that is
filtered by department in accordance with some implementations of
method 200.
[0013] FIG. 7 illustrates an example of an image 700 of a user
interface that presents the identified shared contact data after
applying one or more filters in accordance with some
implementations of method 200.
[0014] FIG. 8 illustrates an example of an image 800 of a user
interface that allows a user to select shared contact data items to
store as private contact data in accordance with some
implementations of method 200.
[0015] FIG. 9 illustrates an example of an image 900 of a user
interface that may be used to determine how selected shared contact
data items are stored as private contact data in accordance with
some implementations of method 200.
[0016] FIG. 10 illustrates an example of an image 1000 of a user
interface that may be used to store search parameters in accordance
with some implementations of method 200.
[0017] FIG. 11 illustrates an example of an image 1100 of a user
interface that may be used to issue a request to reconcile private
contact data with shared contact data in accordance with some
implementations of method 300.
[0018] FIG. 12 illustrates an example of an image 1200 of a user
interface that may be used to identify a source of shared contact
data in accordance with some implementations of method 300.
[0019] FIG. 13 illustrates an example of an image 1300 of a user
interface that may provide a report about the contact data
reconciliation in accordance with some implementations of method
300.
[0020] FIG. 14 illustrates an example of an image 1400 of a user
interface that presents differences between the private contact
data and the shared contact data in accordance with some
implementations of method 300.
[0021] FIG. 15 illustrates an example of an image 1500 of a user
interface that may be used to select and store settings associated
with the reconciliation of the shared contact data with the private
contact data in accordance with some implementations of method
300.
[0022] FIG. 16 illustrates an example of an image 1600 of a user
interface that may be used to receive a request to create or update
an organizational chart for an organization, in accordance with
some implementations.
[0023] FIG. 17 illustrates an example of an image 1700 of a user
interface that may be used to identify an individual to be added to
an organizational chart, in accordance with some
implementations.
[0024] FIG. 18 illustrates an example of an image 1800 of a user
interface that may be used to confirm the addition of an individual
to an organizational chart, in accordance with some
implementations.
[0025] FIG. 19 illustrates an example of an image 1900 of a user
interface that may be used to display a graphical depiction of an
updated organizational chart associated with an organization, in
accordance with some implementations.
[0026] FIG. 20A shows a system diagram 2000 illustrating
architectural components of an on-demand service environment that
may be used to implement a contact data unification method, in
accordance with some implementations.
[0027] FIG. 20B shows a system diagram further illustrating
architectural components of an on-demand service environment that
may be used to implement a contact data unification method, in
accordance with some implementations.
[0028] FIG. 21 shows a system diagram 2110 illustrating the
architecture of a multitenant database environment, in accordance
with some implementations.
[0029] FIG. 22 shows a system diagram 2110 further illustrating the
architecture of a multitenant database environment, in accordance
with some implementations.
DETAILED DESCRIPTION
[0030] Examples of systems, apparatus, and methods according to the
disclosed implementations are described in this section. These
examples are being provided solely to add context and aid in the
understanding of the disclosed implementations. It will thus be
apparent to one skilled in the art that implementations may be
practiced without some or all of these specific details. In other
instances, well known process/method steps have not been described
in detail in order to avoid unnecessarily obscuring
implementations. Other applications are possible, such that the
following examples should not be taken as definitive or limiting
either in scope or setting.
[0031] In the following detailed description, references are made
to the accompanying drawings, which form a part of the description
and in which are shown, by way of illustration, specific
implementations. Although these implementations are described in
sufficient detail to enable one skilled in the art to practice the
disclosed implementations, it is understood that these examples are
not limiting, such that other implementations may be used and
changes may be made without departing from their spirit and scope.
For example, the blocks of methods shown and described herein are
not necessarily performed in the order indicated. It should also be
understood that the methods may include more or fewer blocks than
are indicated. In some implementations, blocks described herein as
separate blocks may be combined. Conversely, what may be described
herein as a single block may be implemented in multiple blocks.
[0032] Conventional methods of storing contact information do not
provide as much contact information for a particular contact as may
be available. "Contact information" may refer to information that
identifies particular traits or distinguishing characteristics
associated with an entity, particularly information for how one can
identify and reach, i.e., contact that entity. The entity may be a
business entity, such as a company, or an individual such as an
employee of a company. By way of example, contact information
associated with the business entity may identify a phone number or
business address that may be used to contact the business entity.
While conventional methods of storing contact information may allow
a user to manually input and store contact information, they do not
provide the user with access to additional sources of contact
information that may be used to enrich the potentially limited
amount of contact information known to the user.
[0033] In one conventional scenario, a user may create a list of
contacts and may store various contact information associated with
each contact included in the list. The contacts may be stored
locally on a computing device, or on a server. While the user may
be provided access to the user's own contact information stored
either locally or remotely, if the user wishes to supplement the
user's contact information, the user must find a way to locate the
additional contact information and update the user's contact
information by inputting the additional contact information
manually. Thus, the user may have to locate and access a website
associated with a business, copy a piece of contact information
associated with the business, such as a phone number, and then
input the phone number into the user's own contact data.
[0034] Some conventional methods of storing contact information do
not provide much, if any, additional information for a contact or
organization. As used herein, an organization can refer to any
entity including any number of individuals and organized for a
common effort or purpose. Examples of an organization include an
enterprise, a company, a corporation, a partnership, a cooperative,
a trust, an academic institution, a charitable organization, and
any combination thereof. In one conventional example, a user of a
database service may only have access to contact information
associated with one contact at a company. The user might only have
a single employee's email address or phone number. However, the
user might not have any other information about the company, such
as names, phone numbers, email addresses or other contact
information regarding the employee's colleagues or other
individuals employed by the company. Furthermore, even if the user
did have access to such additional information, the user would have
to manually input this information in the contact data stored in
the database. Thus, conventional methods remain limited because
they do not provide access to as much information as may be
available, and they sometimes involve laborious data entry.
[0035] The disclosed implementations provide a user with the
ability to access shared contact information stored in a shared
database to which multiple entities contribute contact information.
Thus, shared contact information stored in the shared database may
be "crowd sourced." The disclosed implementations may further allow
the user to retrieve contact information from the shared database.
Because multiple entities contribute information to the shared
database, the shared contact information stored in the shared
database may provide a centralized repository of shared contact
information that has far more contact information associated with a
particular contact than the user's own contact data. In some
implementations, the user may be provided with access to the shared
contact information as part of a database service the user has
subscribed to.
[0036] In one example, the user may store contact information in a
virtual portion of a multi-tenant database system operated and
maintained by an on-demand database service provider. The virtual
portion of the database system may be a portion of the database
system that is provided by the database service provider as part of
a service the user subscribes to, and that is accessible only by
the user and not by other users of the database system. In various
implementations, a virtual portion of the on-demand service
environment is called an "org." Thus, in some implementations, a
user may subscribe to a service provided by a database service
provider. The database service provider may provide the user with
an org in response to the user successfully subscribing to a
particular service. Thus, the org may provide the user with a
portion of the database service provider's database system that
functions as a "sand box" capable of implementing any database
service that the user has subscribed to and is permitted access
to.
[0037] Accordingly, when the user logs in to the user's virtual
portion of the database system, the user may access and view the
user's contact information. The user may be provided with an
indication that additional contact information is available. The
additional contact information may be obtained from the shared
database. Thus, the user may choose to import the additional
contact information into the user's contact information from the
shared contact information. In response to receiving the user's
selection, the database service provider may import the relevant
additional contact information into the user's contact information
automatically.
[0038] The disclosed implementations further provide a user with
the ability to access "crowd sourced" data associated with a
contact, or an organization associated with the contact, and to
retrieve relationship information between or among individuals in
order to generate an organizational chart representing the
relationships between or among individuals of the organization. A
visual presentation of the generated chart can be provided in a
graphical user interface displayed on a computing device. For
example, contact information may be retrieved from the user's
private contact data and shared contact data. The contact
information may indicate relationships between individuals included
in the organization, and such contact information can be
synthesized to determine what hierarchical relationships exist
between the identified individuals.
[0039] In various implementations, the user may request that a
graphical representation of an organizational chart be generated
based on retrieved relationship information. The user may issue
such a request in order to determine whether additional contacts or
sales opportunities exist within the organization. Because the
relationship information may be gathered and determined from crowd
sourced shared contact data as well as the user's own private
contact data, the relationship information may reveal hierarchical
relationships not previously known to the user.
[0040] Thus, according to various embodiments, a database service
provider may identify individuals to include in the organizational
chart and retrieve relationship information identifying
hierarchical relationships within the organization. Once the
hierarchical relationships have been identified, in some
implementations, the database service provider may generate a
graphical representation of the organizational chart for the
organization. In other implementations, the organizational chart
data can be delivered over a network to a user system described
below, and a web browser program or other application running on
the user system can generate the graphical representation for
display in a graphical user interface on a display device. Thus, a
user viewing the display device may be presented with a rendering
of several hierarchical relationships associated with the contact
as well as various other structural information about the
organization of which the contact is a member. In various
implementations, structural information may refer to data
identifying divisions and/or hierarchies in an organization, such
as departments that exist within a company. Structural information
may identify relationships between departments and divisions within
the company. For example, the structural information may include
data values stored in a record, such as a record used to store
contact data. One data value may identify a department within an
organization, such as a sales department. The second data value may
identify a department that the sales department receives directions
from, such as a marketing department. The marketing department
maybe on the same level or on different level than the sales
department in an organizational hierarchy, depending on the
particular organization. Furthermore, the graphical representation
may also present contact information associated with the
individuals identified in the graphical representation of the
organizational chart.
[0041] When presented with a representation of the organizational
chart, the user may not have been previously aware of the displayed
hierarchical relationships or structural information. Thus, by way
of example, the graphical representation of the organizational
chart may inform the user of other contacts, divisions, or sales
opportunities within an organization that the user does business
with. Furthermore, the graphical representation may provide the
user with contact information that may be used to communicate with
the identified contacts and divisions.
[0042] These and other embodiments may be implemented by various
types of hardware, software, firmware, etc. For example, some
embodiments may be implemented, at least in part, by
machine-readable media that include program instructions, state
information, etc., for performing various services and operations
described herein. Examples of program instructions include both
machine code, such as produced by a compiler, and files containing
higher-level code that may be executed by the computer using an
interpreter. Examples of machine-readable media include, but are
not limited to, magnetic media such as hard disks, floppy disks,
and magnetic tape; optical media such as CD-ROM disks;
magneto-optical media; and hardware devices that are specially
configured to store program instructions, such as read-only memory
devices ("ROM") and random access memory ("RAM"). These and other
features and benefits of the disclosed embodiments will be
described in more detail below with reference to the associated
drawings.
[0043] FIG. 1 shows a flowchart of an example of a shared contact
data maintenance method 100, performed in accordance with some
implementations. In various implementations, the method 100 may be
used to receive an indication of updated contact data, determine
credibility information associated with the updated contact data,
and update the shared contact data when the updated contact data is
more credible then the existing contact data.
[0044] In FIG. 1, at block 102, a request to view shared contact
data may be received. In various implementations, a request may be
received when a user of an on-demand database service provided by a
database service provider wishes to view or contribute to shared
contact data.
[0045] In various implementations, the contact data may describe a
particular industry or business associated with the entity. For
example, if the entity associated with the contact data is an
employee of a company or corporation, the contact data may include
the employee's name, occupational title, role within the
organization that employs the individual, the employee's email
address, mailing address, the employee's phone number, fax number,
and an account name associated with the employee. The contact data
may also include various other social network data associated with
the employee, such as a list of which social networks the employee
belongs to, and which "handles", user ID's, or other identifiers
may be associated with the employee within each respective social
network.
[0046] If the entity associated with the contact data is a company
or corporation, the contact data may include information such as
the company's name, phone number, email address, website url,
billing address, and shipping address. The contact data may also
include additional information associated with the company, such as
the total worth of the company, the annual revenue earned by the
company, primary place of business, the number of employees
employed by the company, Dun & Bradstreet (D-U-N-S) number,
Standard Industry Classification (SIC) number, and North American
Industry Classification System (NAICS) number.
[0047] In various implementations, the contact data may comprise
contact data items. Thus, contact data may refer to all available
contact information associated with an entity, such as all
biographical information associated with a sales representative. A
contact data item may refer to a specific data object storing a
piece of information associated with the entity, such as a phone
number associated with the sales representative.
[0048] In various implementations, the contact data may be stored
in one or more records. A record may generally refer to a data
entity, such as an instance of a data object created by a user of
the database service, for example, about a particular entity with
which contact data is associated. The data object can have a data
structure defined by a database service (a standard object) or
defined by a subscriber (custom object). In one embodiment
implementing a multi-tenant database, all of the records for the
tenants have an identifier stored in a common table. In various
implementations, there may be several types of records, each of
which is associated with a particular entity. For example, a
"Contact" record may store information with a contact, such as
biographical information, while a "Lead" record may store
information associated with a lead, such as information regarding a
prospect or potential business opportunity. Furthermore, an
"Account" record may store information associated with an account
belonging to a user's business. The account may be, for example, a
customer, a competitor, or a partner.
[0049] In various implementations, a record has data fields that
are defined by the structure of the object (e.g. fields of certain
data types and purposes). A record can also have custom fields
defined by a user. A field can be another record or include links
thereto, thereby providing a parent-child relationship between the
records. Thus, according to various implementations, contact data
associated with an entity, such as a contact, may be stored in
various data fields included in a record. Each of the fields may
store a contact data item associated with an entity, such as a
contact.
[0050] In various implementations, the contact data may be shared
contact data. Shared contact data may be contact data that is
stored in an on-demand database service environment such that
access to the data is shared by users of the database services
provided by the database service provider. Thus, the shared contact
data may be contributed to and accessible by a plurality of
entities associated with the database service, such as users of the
database service. Thus, a first entity, such as a contact, may have
associated shared contact data stored in a database system. The
shared contact data may include a plurality of shared contact data
items representing contact information associated with the first
entity, such as a business address or occupational title. In
various implementations, a second and third entity may be able to
access the shared contact data and shared contact data items. The
second and third entity may be users of the database service
provided by the on-demand service provider. Moreover, in various
implementations, the second and third entities may be able to edit
the shared contact data items or contribute additional information
to the records storing the shared contact data items. Thus,
according to various implementations multiple entities may access
or contribute information to shared contact data associated with a
single entity. Accordingly, the shared contact data may include
contact data aggregated from several entities. In various
implementations, the entities may be users that subscribe to a
service provided by the database service provider.
[0051] In various implementations, the shared contact data may be
stored in a virtual portion of the database service environment.
The virtual portion may represent a partition of a database system.
In some implementations, the database system may be a multi-tenant
database system. A plurality of settings may define the virtual
portion of the database system. The plurality of settings may
identify which entities have read and write access to the records
stored in the virtual portion of the database system. Thus, the
plurality of settings associated with the virtual portion of the
database may identify what entities have read and write access to
the shared contact data stored within the virtual portion of the
database system. In various embodiments, the plurality of settings
may be set and controlled by the database service provider.
Accordingly, the database service provider may control which
entities have read and write access to the records storing the
shared contact data.
[0052] Returning to FIG. 1, step 102, in various implementations,
the request to view the shared contact data may be received from an
entity, such as a user of the database service. For example, the
request may be in the form of a query issued to a virtual portion
of a multi-tenant database used to store the shared contact data.
Thus, a user of a database service may query a database system, or
more specifically, the virtual portion of the database system
storing the shared contact data to view various shared contact data
items stored therein. The request may be received and handled by
the database service provider which operates and maintains the
database system.
[0053] In FIG. 1, at block 104, an indication of updated contact
data may be received. According to some implementations, updated
contact data may refer to contact data including new or updated
contact information associated with existing shared contact data.
Thus, the updated contact data may include additional or new
contact data items associated with an existing record already
stored in the shared contact data.
[0054] The indication of updated contact data may be a message
issued to the database service provider from a user of the database
service. In various implementations, the indication of updated
contact data may indicate that the user has provided updated
contact data to be included into the shared contact data. Thus, in
various implementations, if a user of the database system attempts
to contribute contact information to the shared contact data, an
indication of updated contact data may be issued to the database
service provider.
[0055] In various implementations, the user may provide updated
contact data in response to being presented with existing shared
contact data. For example, a user may be presented with existing
shared contact data associated with a sales representative at an
organization. The shared contact data may include the occupational
title of the sales representative. The occupational title may be
"sales manager." The user may have learned from a previous
interaction with the sales representative that the sales
representative has a new occupational title that is not currently
reflected in the shared contact data. The new occupational title
may be "regional sales manager." The user may then provide the new
occupational title to the database service provider as updated
contact data. As discussed in greater detail below with regard to
block 110, the database service provider may determine whether or
not the new occupational title should be included in the shared
contact data associated with the sales representative.
[0056] Thus, according to various implementations, the database
service provider may store shared contact data associated with a
contact in a virtual portion of a database, and may receive updated
contact data associated with the contact from at least one user of
the database system. The database service provider may then assess
the credibility of the existing shared contact data already stored
in the database system and the credibility of the updated contact
data to determine which contact data is more credible, and should
be stored for future use.
[0057] Accordingly, in FIG. 1, at block 106, credibility
information for the existing shared contact data may be determined.
Credibility information may provide information about how likely
contact data associated with a contact, such as an organization or
an individual, is true or valid. For example, credibility
information may provide an indication of whether or not a phone
number associated with a contact is a valid phone number or not.
Thus, credibility information may be used to determine whether or
not contact information is credible, and whether or not contact
information should be included in the shared contact data.
[0058] In various implementations, the credibility information may
be determined based on characteristics of the contact data. Such
characteristics may include how recently the contact information
was obtained, how many users have contributed the same or similar
contact information, and whether the contact information is the
proper type of information for a particular type of the shared
contact data item. For example, a phone number submitted as a
contact's name would not be a proper type of information for that
particular type of the shared contact data item, and would not be
deemed credible.
[0059] In various implementations, the credibility information
associated with the existing shared contact data may be determined
by the database service provider. For example, the database service
provider may use characteristics of the contact information to
infer how credible the contact information is. In one example, a
phone number associated with an employee of an organization may be
stored in a data field of a record storing shared contact data
associated with the employee. The phone number may be stored in a
data field identified as the employee's direct line. However, the
phone number may actually be a general contact number associated
with the employee's organization. The database service provider may
infer that the phone number is not the employee's direct phone line
based on characteristics of the phone number. For example, if the
last three digits of the phone number are zeros, the phone number
is not likely to be a direct phone line, and instead more likely to
be the general contact number for the employee's organization.
Based on this determination, the database service provider may
determine that the phone number is not credible.
[0060] In some implementations, the credibility information may be
determined based on characteristics of the source of the contact
data. The source of the contact data may refer to the source of the
indication of updated contact data. For example, the source may be
a user of the database service attempting to contribute updated
contact data to the shared contact data. Characteristics of the
source of the contact data may include the reliability of the
contributor, the response rate of the contributor, the social
influence of the contributor, the seniority of the contributor at
his or her particular organization, and previous credibility
determinations associated with the contributor.
[0061] In various implementations, the credibility information
associated with the existing shared contact data may be stored
within the same record as the existing shared contact data. In some
implementations, the credibility information associated with the
existing shared contact data may be stored in a separate record
than the existing shared contact data. For example, credibility
information, such as how recently a contact data item was
contributed, may be stored in a record separate from the contact
data associated with the credibility information.
[0062] In FIG. 1, at block 108, credibility information for the
updated contact data may be determined. The credibility information
for the updated contact data may provide information indicative of
the credibility of the updated contact data. Similar to the
credibility information discussed above at step 106 and with
respect to the existing contact data, credibility information
associated with the updated contact data may be inferred from
contact data itself, or from the source of the contact data. The
credibility information associated with the updated contact data
may be stored in the same record or a different record as the
updated contact data.
[0063] As discussed above with respect to block 106, the
credibility information for the updated contact data may be
determined based on the data obtained from a user of a database
service provided by the database service provider. The credibility
information may then be stored by the database service
provider.
[0064] In FIG. 1, at block 110, it may be determined whether the
updated contact data or the existing shared contact data is more
credible. In various implementations, the database service provider
may determine which contact data is more credible based on a
comparison between the credibility information associated with the
existing shared contact data and the credibility information
associated with updated contact data.
[0065] In various implementations, the determination of which
contact data is more credible may be made in accordance with
several criteria. Thus, the criteria may specify a set of rules
used to make the determination. For example, the criteria for
making a credibility determination may specify that recent contact
information is more credible than older contact information. In
this instance, the database service provider may compare a value
stored in a data field used to store credibility data associated
with the more recent contact data with a value stored in a data
field used to store credibility data associated with the older
contact data. The credibility data may, for example, identify when
contact data associated with the credibility data was contributed.
Upon comparing the different values, the database service provider
may use the established criteria for making the credibility
determination in order to determine that the more recent contact
data is more credible than the older contact data.
[0066] In various implementations, the criteria used to make a
credibility determination may be specified by the database service
provider. Thus, the database service provider may determine the
criteria and rules used as the basis of the credibility
determination. For example, the database service provider may
determine that a credibility determination may be made based on a
position within a hierarchy of an organization. For example, the
database service provider may specify that contact information
provided by a manager of a company is more credible than contact
information received from an employee subordinate to the manager
because the manager has a higher position in the organization's
hierarchy. In this instance, if both the manager and the employee
submitted conflicting contact data, the contact information
submitted by the manager would be determined to be more credible
based on his higher position within the hierarchy of the
organization. It will be appreciated that various other criteria
may be used for various characteristics associated with the contact
information itself, and the contributor of the contact
information.
[0067] In some implementations, the criterion used to make the
determination may be stored in a database as a record. Thus, the
record may include a plurality of data fields used to store the
criteria that form the basis of the credibility determination. In
various implementations, the record storing the criteria may be
recalled at a later time during a subsequent determination. Thus,
the stored criteria may be applied to multiple credibility
determinations.
[0068] In various implementations, the database service provider
may use the above-referenced criteria to determine whether the
updated contact data or the existing shared contact data is more
credible. Thus, the database service provider may compare
credibility information associated with the updated contact data
with credibility information associated with the existing shared
contact data in accordance with various criteria specified by the
database service provider.
[0069] If it is determined that the existing shared contact data is
more credible than the updated contact data, in FIG. 1, at block
112, the existing shared contact data may be retained. As discussed
above with respect to block 106, the existing shared contact data
may be stored as a record in a multi-tenant database system. If the
existing shared contact data is more credible than the updated
contact data, the record storing the existing shared contact data
remains unchanged, and the values stored within the record remain
unchanged. Thus, according to various implementations, the existing
shared contact data is retained, while the updated contact data may
be discarded.
[0070] In various implementations, instead of being discarded, the
updated contact data may be stored in a separate record. The
separate record may be referred to in future credibility
determinations if the information stored in the separate record is
relevant. For example, if an address associated with an
organization is submitted to the database service provider as
updated contact data but determined to be less credible than the
address already stored in the existing shared contact data, the
submitted address may be stored in a separate record in the
database service provider's database. If the discarded address is
submitted again by a different user, the database service provider
may query the database storing the separate records to determine
how many times this address has been submitted. The database
service provider may then factor that information into the
credibility determination. For example, if that address has been
submitted several times, it may be deemed more credible than if had
only been submitted once.
[0071] If it is determined that the updated contact data is more
credible than the existing shared contact data, in FIG. 1, at block
114, the existing shared contact data may be replaced by the
updated contact data. Thus, the appropriate values of the data
fields of the record storing the existing shared contact data may
be overwritten with the values of the updated contact data.
Returning to a previous example, an address associated with an
organization may be submitted to the database service provider as
updated contact data. If the address is deemed more credible than
the address stored in the existing shared contact data, the
existing shared contact data may be overwritten, thus updating the
existing shared contact data with the new address of the
organization.
[0072] FIG. 2 shows a flowchart of an example of a contact data
search method 200, performed in accordance with some
implementations. In various implementations, method 200 may be used
to receive a request to search or filter shared contact data,
select shared contact data based on search or filter parameters,
and store selected contact data as private contact data.
[0073] In FIG. 2, at block 202, a request to search or filter
shared contact data may be received. A user may issue such a
request to locate additional contact information. In various
implementations, the user may have stored private contact data
within the user's own virtual portion of the database system.
Private contact data may be contact data that has been provided by
the user and is only accessible by the user. For example, a user
may log into a virtual portion of the database service environment
that has been provided by the database service provider as part of
a database service that the user subscribes to. This virtual
portion may be a portion of the database service environment that
is fully accessible by the user, but is not accessible by other
entities using the database service environment. Thus, contact data
stored in the user's virtual portion of the database is private
contact data because other users of the database service do not
have access to it.
[0074] The user may determine that additional contact information
should be obtained. For example, the user may have stored contact
data associated with a group of sales representatives in a sales
division associated with a company. However, the private contact
data may be missing specific contact data items, such as a fax
number associated with one of the sales representatives. Moreover,
there may be other sales representatives within that sales division
for whom the user has no contact information. Thus, the user may
issue a request to search the shared contact data for additional
contact information that may provide additional information about
contacts that already exist within the user's own private contact
data, and additional contacts that don't already exist in the
user's private contact data.
[0075] In some implementations, the user may issue the request
through a user interface. The user interface may be provided by the
database service provider to the user at a computer system. In
various implementations, the computer system may be a personal
computer, a mobile computing device, or a mobile telecommunications
device. Thus, the user interface may be presented to a user through
one of several computing platforms, such as a mobile platform or a
personal computer.
[0076] In various implementations, the request may be a message
that includes information, such as search or filter parameters
specified by the user that forms the basis for searching and
filtering the shared contact data. Thus, the specified information
may be used to query a database storing shared contact data. In
some implementations, the database may be operated and maintained
by the database service provider, and the request to search or
filter the shared business contact data may be received by the
database service provider.
[0077] In FIG. 2, at block 204, search or filter parameters for
retrieving shared contact data may be identified. The search or
filter parameters may form the basis for searching or filtering
shared contact data stored and maintained by the database service
provider. Thus, the database service provider may use the search
and filter parameters to identify shared contact data items and
return the results of a search requested by the user.
[0078] In various implementations, a search parameter may be a
parameter that identifies contact data items that are relevant to
the user's request. In various implementations, the search
parameter may be associated with a specific data field of shared
contact data records used to store shared contact data. The search
parameter may identify a value that may be stored in the associated
data field. For example, the search parameter may identify a value
representing a company name, an occupational title, a geographic
location, an industry, or a sub-industry. In one example, the
search parameter may be associated with an occupational title
associated with a contact. The search parameter may identify a
specific occupational title, such as "regional sales manager."
Records storing shared contact data may each include a data field
storing an occupational title associated with a contact. Thus, the
identified search parameter, i.e. the occupational title, may
correspond to a data field included in the shared contact data
records. Furthermore, a search performed based on the search
parameter may search values stored in the corresponding data fields
of the shared data records. For example, the search may be
performed on data fields associated with an occupational title.
Contact data items returning a value of "regional sales manager"
may be identified and returned.
[0079] In various implementations, a filter parameter may be a
parameter that identifies how items returned by the search are
sorted or filtered. For example, a filter parameter may be a
company name, a department at which an employee works, or a level
of seniority associated with an employee. In various
implementations, the filter parameter may be provided by the user
after the search has returned a plurality of shared contact data
items based on a search parameter. Thus, according to some
implementations, the user may be presented with the results of the
search at the user interface.
[0080] In various embodiments, the database service provider may
identify search and filter parameters based on information included
in the request issued by the user. As discussed with respect to
FIG. 2, block 202, the user may specify search and filter
parameters when formulating the request. Thus, the message may be a
record that includes several data fields storing the specified
parameters. The database service provider may identify the search
and filter parameters based on the values stored in the data fields
of the message. Therefore, upon receiving the request, the database
service provider may identify the search and filter parameters
based on the parameters specified by the user.
[0081] In FIG. 2, at block 206, shared contact data may be
identified based on the identified parameters. Thus, the database
service provider may search the shared contact data based on the
identified search and filter parameters and identify shared contact
data items that satisfy the search and filter parameters. As
previously discussed, a record storing shared contact data may
include a plurality of data fields, each of the data fields storing
a shared contact data item representing contact information that
may be associated with an entity. If a record stores a contact data
item representing a value identified by the search parameter, the
record may be returned as a search result.
[0082] In FIG. 2, at block 208, the identified shared contact data
may be presented to a user at a user interface. Accordingly, the
user may be presented with the results of the search which may
include additional contact information not presently stored in the
user's private contact data. Moreover, the presentation of the
identified shared contact data may be filtered according to the
user's preference, thus presenting the results in a manner
specified by the user.
[0083] In various implementations, the identified shared contact
data returned by the search may be filtered dynamically. Thus, all
search results may be presented to the user at the user interface.
The user may then select and apply filters to the returned search
results in response to being presented with the search results. For
example, the user may select and apply a first filter to the search
results, such as a name of a business. The user may then select and
apply a second filter, such as a department associated with the
business. In some implementations, the second filter may be applied
to the original search results, and the first filter may be removed
in response to the user selecting the second filter. In various
implementations, the search results may be filtered according to
both the first and second filter in response to the user selecting
the second filter.
[0084] FIG. 6 illustrates an example of an image 600 of a user
interface displaying identified shared contact data that is
filtered by department in accordance with some implementations of
method 200. In one example, image 600 of the user interface may
include data fields 602, 604, and 606.
[0085] Data field 602 may include a plurality of data fields
associated with the shared contact data. The user may enter the
search parameters into the plurality of data fields. The search
parameters may be used to perform a search that identifies a
plurality of shared contact data items based on the search
parameters. In this instance, a parameter of "www.ucshealth.org"
has been chosen and entered into a data field identified as
"Company or Website." Thus, a search may be performed to identify
and return records storing shared contact data that include a value
of "www.ucshealth.org" in a field identified as "company" or
"website."
[0086] Data field 604 may include a plurality of data fields
allowing the user to select filters to apply to the shared contact
data items returned by the search. In various implementations, the
filters available to the user may be organized into groups. For
example, the filters may be organized or grouped according to type
of information associated with an organization. In this instance,
the filters are organized according to "company name,"
"department," and "level," where "level" identifies a contact's
level within the hierarchy of an organization. In various
implementations, a contact's level within an organization may be
inferred by the contact's occupational title and known
relationships between occupational titles.
[0087] Data field 606 may include the plurality of shared contact
data items that have been returned by the search based on the
search parameters specified in data field 602, and filtered
according to the filter parameters specified in data field 604.
Data field 606 may include a plurality of data fields displaying
various shared contact data items. In this instance, data field 606
may display a contact's name, email address, phone number, company
or employer, occupational title, and geographical location. Data
field 606 may also display an indication of the last time the
shared business contact data item was updated. As shown in data
field 606, information associated with a plurality of contacts may
be simultaneously presented to the user at the user interface.
[0088] FIG. 7 illustrates an example of an image 700 of a user
interface that presents the identified shared contact data after
applying one or more filters in accordance with some
implementations of method 200. As shown in data field 702, multiple
filters may be applied simultaneously to the shared contact data
items returned by the search. In this instance, the user has chosen
to apply a filter of "IT & IS," "Director-Level," and
"Manager-level." Accordingly, the returned items may be filtered
according to a department and level associated with each shared
contact data item. As shown in data field 704, only contacts having
a company of "UCSF Medical Center" (as identified by the search
parameter), having a level (e.g. occupational title) equivalent to
"Director" or "Manager," and having a department of "IT" or "IS"
are returned by the search and displayed to the user.
[0089] Returning to FIG. 2, at block 210, a selection of contact
data items may be received. The selection of contact data items may
be made by the user through the user interface in response to being
presented with the shared contact data identified by the search.
The selection may identify specific contact data items that the
user has chosen to integrate into the user's own private contact
data. Thus, the user may determine which of the identified shared
contact data items should be stored, and which of the identified
shared contact data items should not be stored.
[0090] FIG. 8 illustrates an example of an image 800 of a user
interface that allows a user to select shared contact data items to
store as private contact data in accordance with some
implementations of method 200. Data field 802 may display various
information associated with a plurality of shared contact data
items that have been returned by a search based on a search
parameter, and that have been filtered according to at least one
filter parameter. In various implementations, data field 804 may
include a plurality of data fields, each of the data fields being
associated with one of the returned items. Each of the data fields
may receive an input that indicates that the returned shared
contact data item associated with the data field has been selected
to be stored as private contact data. In this instance, the
plurality of data fields is comprised of several checkboxes. Thus,
according to various embodiments, the user may check a checkbox
next to each returned item that the user determines should be
included in the private contact data. Data field 806 may receive an
input from the user indicating that the selected shared contact
data items should be stored as private contact data. In this
instance, data field 806 may provide a drop down box that
identifies a location where the items should be stored. In various
implementations, the location may be the user's own virtual portion
of the database system.
[0091] Returning to FIG. 2, at block 212, the selected contact data
items may be stored. In various implementations, the selected
contact data items may be stored locally in the user's own computer
system. Thus, a user may select specific contact data items that
the user has determined should be included in the user's private
contact data, and then store the selected contact data items
locally. As previously discussed, the local computer system may be
a personal computer or a mobile device. When stored locally, the
user may access the contact data without a connection, such as a
network connection, to the database service provider.
[0092] Moreover, according to various implementations, the user's
private contact data may be stored in a virtual portion of a
multi-tenant database. Accordingly, while the user interface may be
presented to the user at a local computer system, the user's
private contact data may be stored remotely in a multi-tenant
database system that is part of a cloud-based on-demand database
service environment. In this example, the selected contact data
items may be stored in the virtual portion of the database system
associated with the user. In various implementations, the contact
data may be stored both locally and remotely.
[0093] In some implementations, the user may determine what type of
record is used to store the shared contact data. As previously
discussed with respect to FIG. 1, block 102, a record may be one of
several types of record. For example, a record may represent a
contact, lead, or account. Thus, according to various
implementations, the user may determine whether the selected
contact data is stored as a contact, a lead, or as an account.
[0094] FIG. 9 illustrates an example of an image 900 of a user
interface that may be used to determine how selected shared contact
data items are stored as private contact data in accordance with
some implementations of method 200. A user may be provided with the
user interface illustrated by image 900 in response to the user
selecting shared contact data items to store. Data field 902 may
provide the user with a list of options that may allow the user to
determine how the selected shared contact data items are stored.
For example, the user may provide an input to data field 902 that
identifies what type of record a selected contact data item belongs
to. In this instance, data field 902 has presented the user with
the option of storing the selected contact data items as "Leads" or
"Contacts." In this instance, the user has chosen "Contacts."
Accordingly, the selected shared contact items may be stored in the
private contact data as "Contacts." In various implementations, if
a selected shared contact data item already exists in the private
contact data, the selected item is not stored.
[0095] Returning to FIG. 2, at block 214, the shared contact data
search parameters may be stored. Thus, in various implementations,
in addition to storing the selected shared contact data items, the
database service provider may also store the parameters used to
identify the selected shared contact data items. As similarly
discussed with reference to FIG. 2, block 212, the search
parameters may be stored locally or remotely. In various
implementations, the stored search parameters may be retrieved and
used for future searches performed by the user.
[0096] In various implementations, the stored search parameters may
provide a search history accessible by the user. For example, upon
initiating a search, the user may access the user's search history
and recall a previous search performed with parameters previously
entered by the user. Thus, according to various implementations,
the user may recall the results of a previously performed search
based on the stored parameters.
[0097] FIG. 10 illustrates an example of an image 1000 of a user
interface that may be used to store search parameters in accordance
with some implementations of method 200. As illustrated by data
field 1002, the results of a search based on search and filter
parameters may be displayed at a user interface. In various
implementations, data field 1004 may be used to save the search and
filter parameters, as well as the results of the search. In this
instance, data field 1004 provides the user with the option to save
the search for future use. Thus, according to various
implementations, a user may provide an input to data field 1004,
such as selecting "Save Search As," and save the search and filter
parameters as well as the search results. The saved search results
and parameters may be recalled at a future time. Moreover, in some
implementations, a user may specify where a data object including
the saved search should be stored. For example, the user may
specify that the search results should be stored in a virtual
portion of a database system associated with the user, or stored at
a local computer system associated with the user.
[0098] FIG. 3 shows a flowchart of an example of a contact data
reconciliation method 300, performed in accordance with some
implementations. In various implementations, the method 300 may be
used to receive a request to reconcile private contact data with
shared contact data, compare the private contact data to the shared
contact data to identify differences, and reconcile the differences
between the private contact data and the shared contact data. Thus,
data reconciliation method 300 may be used to integrate contact
data aggregated from several sources with a user's private contact
data in order to enrich the user's private contact data.
[0099] In FIG. 3, at block 302, a request to reconcile private
contact data with shared contact data may be received. In various
implementations, reconciling the private contact data with the
shared contact data may comprise a process in which differences
between the two sets of data are resolved to create a unified data
set. In some implementations, the request to reconcile private
contact data may be issued by a user of a database service provided
by a database service provider. The user may issue the request to
reconcile the user's private contact data in order to import
additional contact information into the user's private contact data
from shared contact data, or to evaluate and reconcile differences
between the private contact data and the shared contact data.
[0100] FIG. 11 illustrates an example of an image 1100 of a user
interface that may be used to issue a request to reconcile private
contact data with shared contact data in accordance with some
implementations of method 300. In some implementations, image 1100
may present a user with private contact data. Thus, image 1100 may
display information associated with a specific entity or contact.
For example, data field 1102 may display information regarding the
identity of the entity or contact with which the displayed private
contact data is associated. In this instance, data field 1104
displays various private contact data items, such as a title,
department, birthdate, mailing address, and phone number. Data
field 1102 indicates that the information is associated with a
contact named "Tim Barr."
[0101] Data field 1106 may present the user the option of
reconciling the user's private contact data, as identified by data
field 1102, with shared contact data that has been aggregated from
several other users. In this instance, data field 1106 provides the
user with a button. If the user selects the button, a request to
reconcile the private contact data with the shared contact data may
be issued to the database service provider.
[0102] Data field 1110 may provide information about previously
issued requests to reconcile data. Thus, in some implementations,
data field 1110 may provide historical information about previous
data reconciliations. In various implementations, data field 1110
may also indicate whether or not a request to reconcile data should
be issued. For example, data field 1110 may include data field
1112, which may provide the user with an indication of the status
of the private contact data. The status may refer to whether or not
any discrepancies between the user's private contact data and the
shared contact data exist. In this instance, data field 1112
indicates a status of "Clean." Accordingly, the status identified
by data field 1112 indicates that the private contact data is
consistent with the shared contact data because no differences
exist. Thus, the information stored in the private contact data is
as current as possible. In various implementations, data field 1112
may also indicate that the status of the private contact data is
not "Clean." Accordingly, data field 1112 may indicate that more
recent, or different, information is available from the shared
contact data, and the contact data should be reconciled. Data field
1110 may also include data field 1114, which may provide additional
historical information about the reconciliation process. For
example, data field 1114 may indicate when the last request to
reconcile data was issued, and when the status of the private
contact data was last checked.
[0103] Returning to FIG. 3, at block 304, a source of private
contact data may be identified. In various implementations, the
source of the private contact data is the location at which the
private contact data is stored. As previously discussed with
reference to FIG. 2, block 212, the private contact data may be
stored locally or remotely. For example, the private contact data
may be stored at a computer system or mobile device used by the
user. Moreover, the private contact data may be stored remotely in
a multi-tenant database system operated and maintained by a
database service provider.
[0104] In FIG. 3, at block 306, a source of shared contact data may
be identified. In various implementations, the source of the shared
contact data is the location at which the shared contact data is
stored. As previously discussed with reference to FIG. 1, block
114, the shared contact data may be stored in a virtual portion of
a multi-tenant database system operated and maintained by the
database service provider. Thus, according to various
implementations, the database service provider may identify the
source of the shared contact data by determining the location at
which the shared contact data is stored.
[0105] In some embodiments, the source of the shared contact data
may further refer to a particular record or data object that stores
shared contact data items relevant to the private contact data that
is the basis of the reconciliation. For example, the source of the
shared contact data may refer to a record that stores shared
contact data items for a particular contact. In some
implementations, the source of the shared contact data may be a
plurality of records or data objects.
[0106] FIG. 12 illustrates an example of an image 1200 of a user
interface that may be used to identify a source of shared contact
data in accordance with some implementations of method 300. Data
field 1202 may display information about identified private contact
data that may form the basis of the reconciliation process. In this
instance, data field 1202 displays the name, title, company, email
address, and phone number of the contact associated with the
identified private contact data. Data field 1204 may display
different sources of shared contact data that are available and
that may be reconciled with the private contact data. In this
instance, the sources are different records storing shared contact
data. The user may determine which source of the shared contact
data is relevant to reconciling the identified private contact data
based on the information displayed in data field 1202. In this
instance, each of the records is associated with a contact named
"Tim Barr." However, each of the records has varying contact
information. The user may identify which record is most relevant,
and choose to reconcile the user's private contact data with the
identified record.
[0107] Data field 1206 may receive an input that identifies which
source of shared contact data should be used to reconcile the
private contact data with the shared contact data. In this
instance, the data field provides a button capable of receiving a
selection of from the user. Thus, in various implementations, the
user may select a source of shared contact data that should be
reconciled with the private contact data by selecting the
appropriate button corresponding to that data source.
[0108] Returning to FIG. 3, at block 308, the private contact data
may be compared to the shared contact data. Differences between the
private contact data and the shared contact data may be determined
based on this comparison. For example, private contact data items
associated with a contact, such as a sales representative employed
by a company, may be stored in a first record as private contact
data. The first record may include a plurality of data fields
storing the various contact data items associated with the sales
representative. For example, the first record may store the sales
representative's business address and email address. However, the
record might not include the sales representative's business phone
number. A second record associated with the sales representative
may be stored in the shared contact data. The second record may
include the sales representative's business phone number. Thus,
according to various implementations, when the first record stored
as private contact data is compared to the second record stored as
shared contact data, a difference between the first and second may
be identified. The difference may indicate that the shared contact
data includes the sales representative's business phone number,
while the private contact data does not.
[0109] In various implementations, a report based on the comparison
of the private contact data with the shared contact data may be
provided. The report may provide metadata regarding the comparison.
Thus, the report may provide an overall indication of how a user's
private contact data compares to the shared contact data. For
example, the report may indicate how many duplicate contact data
items are present (i.e. present in both the private contact data
and shared contact data). The report may also indicate how many
records associated with contacts are missing information and do not
have a contact data item for a particular field. The report may
further indicate how much of the user's contact data is incorrect.
This may be based on an overall determination of how many shared
contact data items conflict with or have different values than the
private contact data items. As similarly discussed with reference
to FIG. 1, blocks 106 through 110, the credibility of both the
shared contact data items and the private contact data items may be
used to determine how many of the conflicting private contact data
items are less credible than the shared contact data items, and
thus incorrect.
[0110] FIG. 13 illustrates an example of an image 1300 of a user
interface that may provide a report about the contact data
reconciliation in accordance with some implementations of method
300. The report displayed in image 1300 may be provided to a user
after the reconciliation process has been completed. Data field
1302 may display information summarizing the results of the
reconciliation process. In various implementations, data field 1302
displays the number of contacts for which shared contact
information was imported and stored as private contact data. In
this instance, data field 1302 indicates that contact data was
imported for 12,000 contacts.
[0111] Data field 1304 may provide additional information about the
contact data that was imported. In various implementations, data
field 1304 may identify how many shared contact data records were
already present in the private contact data. In this instance, data
field 1304 may identify these occurrences as "Duplicates." Data
field 1304 may represent the number of duplicate entries as a
percentage, or a raw number. In this instance, 4,400 duplicate
contacts were found.
[0112] Data field 1306 may provide information about deficiencies
of the private contact data after the reconciliation process. In
this instance, data field 1306 identifies such deficiencies as
"Missing Information." Data field 1306 may represent the missing
information as a percentage of missing contact data. The percentage
may be based on a relationship between the total number of records
capable of storing private contact data items and the number of
those records that include empty data fields. In addition to
providing a percentage, data field 1306 may provide a raw number of
contacts that have missing information. In this instance, 2500
contacts have missing contact information.
[0113] Data field 1308 may provide information about the
differences between the private contact data and the shared contact
data. In this instance, data field 1308 identifies the differences
as "Incorrect Information." Data field 1308 may represent the
differences as a percentage based on a relationship between the
total number of data fields storing private contact data and the
number of private contact data items that conflict with the shared
contact data and have been deemed less credible than the shared
contact data. Furthermore, data field 1308 may provide a raw number
of conflicting contact data items that were found. In this
instance, 8,160 contacts had contact data that conflicted with the
shared contact data and was less credible than the shared contact
data.
[0114] In various implementations, the indication of differences
between the private contact data and the shared contact data may be
presented as a side by side comparison displayed at the user
interface. FIG. 14 illustrates an example of an image 1400 of a
user interface that presents differences between the private
contact data and the shared contact data in accordance with some
implementations of method 300. As discussed above with reference to
FIG. 11, at data field 1102, data field 1402 may display
information regarding the identity of the entity or contact with
which the displayed private contact data is associated. Data field
1404 may display various private contact data items, such as a
title, mailing address, email address, fax number, and phone
number.
[0115] Data field 1404 may include data field 1406. Data field 1406
may display information identifying the status of the private
contact data. The status may refer to whether or not the private
contact data is consistent with or the same as the shared contact
data. Thus, according to various implementations, data field 1406
may provide an overall indication of whether or not the private
contact data associated with a contact, in this instance "David
Adelson," is the same as the identified shared contact data
associated with this contact. In this instance, because differences
exist between the data sets, data field 1406 indicates a status of
"different." Moreover, data field 1406 may further present the user
the option of reconciling all data associated with the contact.
[0116] Data field 1404 may also include data field 1410. Data field
1410 may provide an indication of whether or not a specific private
shared contact data item associated with a contact is consistent
with or the same as the corresponding shared contact data item
stored in a shared contact data record associated with the contact.
Thus, in various implementations, data field 1410 may display
status information associated with a single private data contact
item. In this instance, there is a difference between a phone
number stored in the private contact data associated with "David
Adelson" and the shared contact data associated "David Adelson." In
response to being presented with the indication of this difference,
the user may select to reconcile the difference by replacing the
private contact data with the shared contact data.
[0117] In some implementations, the user may choose to view the
shared contact data before choosing to reconcile the differences.
Accordingly, in various implementations, data field 1412 may be
presented to the user in response to receiving the selection to
reconcile the difference. Data field 1412 may display the shared
contact data item that is different from the private data contact
item. In this instance, the shared contact data includes a phone
number that is different from a phone number stored in the private
contact data. The user may compare the two contact data items and
determine how to reconcile the difference between the two.
[0118] Returning to FIG. 3, at block 310, the differences between
the private contact data and the shared contact data may be
reconciled. Reconciliation may be performed by the user. Thus,
according to various implementations, the user may be presented
with an indication of differences between the private contact data
and the shared contact data, and in various implementations, the
user may reconcile differences between the two sets of data by
selecting which data should be retained. Returning to FIG. 14, the
user may reconcile the differences by providing an input to data
field 1414. The input received by data field 1414 may identify
whether the private contact data or the shared contact data should
be stored. In this instance, data field 1414 provides the user with
a "thumbs up" and a "thumbs down." If the user selects the "thumbs
up," the user has indicated that the phone number stored in the
shared contact data item is good, and should be stored instead of
the private contact data already stored in the user's private
contact data. If the user selects the "thumbs down," the user has
indicated that the phone number stored in the shared contact data
item is bad, and should not be stored instead of the user's private
contact data.
[0119] In some implementations, settings may be used to determine
how and when reconciliation of differences between shared contact
data and private contact data occurs automatically. For example, if
a particular difference, such as missing private contact data, is
identified, a specific action may be taken to reconcile the
difference. In various implementations, the action may be taken
automatically by the database service provider. In one example, a
user's private contact data may be missing a contact data item that
identifies an occupational title associated with a sales
representative that the user is currently negotiating with.
However, shared contact data associated with the sales
representative may include a contact data item that identifies the
occupational title of the user. The occupational title of the sales
representative may be of value to the user because it provides
additional information about the sales representative's position in
the hierarchy of the sales representative's organization. A setting
may indicate that this difference should be reconciled by
automatically importing the shared contact data item into the
private contact data. In various implementations, the user may
determine the setting.
[0120] FIG. 15 illustrates an example of an image 1500 of a user
interface that may be used to select and store settings associated
with the reconciliation of the shared contact data with the private
contact data in accordance with some implementations of method 300.
In various implementations, the settings may be particular to a
type of record. For example, a first set of settings may be stored
and applied to Contacts, while a second set of settings is stored
and applied to Groups. Data field 1502 may display information
identifying which type of record the settings are applicable to. In
this instance, data field 1502 indicates that the settings
displayed in image 1500 are applied to "Leads." Data field 1504 may
include several data fields that may be associated with data fields
particular to a type of record used to store contact data items.
For example, data field 1504 may include a field associated with
the name of a contact.
[0121] Data field 1506 may include several settings associated with
the data field identified by data field 1504. The settings may
identify actions to be taken in specific circumstances. Thus, the
settings may identify when private contact data should be updated
with, or overwritten by, shared contact data. In this instance, the
actions identified in data field 1506 are "Update values," "Update
only empty values," and "Don't update values." Accordingly, the
values stored in the private contact data may always be updated
automatically upon initiation of the reconciliation process, only
if the corresponding data item stored in the private contact data
is empty, or not automatically updated at all. Data field 1506 may
receive an input from the user that selects a setting for a data
field identified by field 1504.
[0122] Data field 1508 may provide a data field capable of
receiving a selection to share the private contact data with the
shared contact data. Thus, in addition to determining to retain the
user's private contact data instead of replacing it, the user may
further decide to share the private contact data with the shared
contact data stored by the database service provider. In this
instance, data field 1508 provides a plurality of checkboxes. Each
checkbox may be associated with a data field identified by data
field 1504. If a checkbox is selected, the private contact data
item stored within the data fields may be communicated to the
shared contact data, and incorporated into the shared contact data
if deemed credible, as previously discussed with reference to
process 100.
[0123] Returning to FIG. 3, at block 312, the updated private
contact data may be stored. As previously discussed with reference
to FIG. 3, block 304, the private contact data may be stored
locally or remotely. Thus, according to various implementations,
the updated private contact data that has been reconciled with the
shared contact data may also be stored locally or remotely.
[0124] In FIG. 3, at block 314, updated shared contact data may be
stored. Thus, according to various implementations, the user's
selection may be used to determine whether or not the shared
contact data should be updated. If the user determines that the
user's own data should be stored in the private contact data and
that the shared contact data value should be discarded, the
database service provider may perform a credibility determination
as discussed with respect to FIG. 1, blocks 106 through 114, to
determine if the user's private contact data is more credible than
the shared contact data. If it is determined that the user's
private contact data is more credible, the shared contact data may
be updated with the private contact data, and the updated shared
contact data may be stored by the database service provider in a
database system associated with the database service.
[0125] FIG. 4 shows a flowchart of an example of an organization
chart construction method 400, performed in accordance with some
implementations. In various implementations, organization chart
construction method 400 may be used to generate an organizational
chart of an organization that identifies individuals included in
the organization, and identifies hierarchical relationships between
those individuals. For example, a graphical representation of the
organizational chart of a company may provide a visual presentation
of all employees within the company or a group of the company as
well as connections and hierarchical relationships defined by the
connections among the employees, such as team-level and user-level
management relationships, e.g., which employee supervises or
reports to which employee, and visa versa. Furthermore, in various
implementations, the organizational chart may identify additional
information, such as how a company is structured, e.g., what
departments and divisions exist within the company, and what
hierarchies of employees and groups of employees exist within those
departments and divisions. Thus, organization chart construction
method 400 may be used to create a graphical representation of an
organizational chart of an organization that provides detailed
information about an organization that might not otherwise be
available to a user of a database system.
[0126] In FIG. 4, at block 402, a request to generate a graphical
representation of an organizational chart associated with an
organization may be received. In some implementations, the
organizational chart provides a visual presentation of individuals,
teams, departments, divisions, or other entities within the
organization, as well as any structural information indicating
hierarchical or other relationships between such individuals,
teams, departments, divisions, or other entities for that
particular organization. In various implementations, a user of a
database system may issue such a request to obtain more information
about an organization associated with a contact that the user may
know. For example, the user may know a sales manager through
various business dealings. In order to increase the user's own
sales opportunities, the user may wish to know more about who the
sales manager works for, and what other sales divisions exist
within the sales manager's company. Thus, the user may issue a
request to retrieve information about the company and generate a
graphical representation of an organizational chart for the
company.
[0127] In FIG. 4, at block 404, a first individual to include in
the organizational chart may be identified. In various
implementations, in response to receiving the request of block 402,
the database service provider may identify one or more individuals
to include in the organizational chart. In some implementations,
the individual(s) may be identified based on the contact originally
selected by the user. Therefore, in various implementations, if a
user requests a graphical representation of an organizational chart
for an organization associated with a contact (such as the company
that employs the sales manager), the database service provider may
use the contact as the basis for creating the organizational chart.
In various implementations, the database service provider may also
query a database system for contact data identifying other
individuals that are employed by the organization. In some
implementations, the contact data may also or alternatively be
shared contact data that is crowd sourced, as described above.
Thus, in addition to identifying the contact originally selected by
the user, the database service provider may identify other contacts
that are also employed by the same organization.
[0128] In FIG. 4, at block 406, relationship information associated
with the first individual may be identified. In various
implementations, the relationship information may identify
hierarchical relationships between the first individual and a
plurality of second individuals associated with the organization.
For example, a first individual employed by an organization may
supervise a second individual at that organization. Thus, the
hierarchical relationship between the first and second individual
may be supervisor/supervisee. In various implementations, the
database service provider may query various databases to retrieve
data identifying hierarchical relationships associated with the
first individual. In various implementations, data identifying
hierarchical relationships associated with the first individual may
refer to additional data included in private and/or shared contact
data that provides information about the first individual's place
of business, and at least a second individual that works at the
first individual's place of business. According to various
implementations, the data may be retrieved from shared contact data
associated with the first individual. Accordingly, the database
service provider may query a database storing contact information
that is "crowd sourced" and contributed to by many entities, such
as other users of database services. In doing so, the database
service provider may retrieve relationship information from a
database that has much more information than the user has access
to.
[0129] In various implementations, hierarchical relationships may
be determined based on the retrieved data. In some implementations,
a particular type of data field included in contact data records
may store a data value identifying a hierarchical relationship
associated with an individual. For example, an individual's contact
data record may include a field that identifies the individual's
supervisor. In various implementations, the data field may be
queried in order to identify and determine the individual's
supervisor.
[0130] In some implementations, a machine algorithm implemented by
a database service provider may infer hierarchical relationships
based on the retrieved data. For example, the machine algorithm may
determine hierarchical relationships based on an individual's level
within an organization or department. In some implementations, the
machine algorithm may group retrieved data for individuals within
an organization, or departments within the organization, by level.
The machine algorithm may determine hierarchical relationships
between the first individual and a second individual based on known
or designated hierarchical relationships between their respective
levels within the organization or departments of the
organization.
[0131] In FIG. 4, at block 408, the organizational chart may be
generated based on the first individual and the relationship
information. The database service provider may then generate an
organizational chart that illustrates how a hierarchy of members or
employees of the organization is structured, and how the
organization itself is structured. Examples of organizational
charts and graphical representations of such are set forth in the
FIGs. and the description below. Thus, in various implementations,
the organizational chart identifies individuals included in the
organization and identifies hierarchical relationships between the
individuals. In some implementations, the organizational chart is
capable of being displayed at a user interface of a display device.
Thus, the organizational chart may be displayed as a graphical
representation to the user at a user interface.
[0132] FIG. 5 shows a flowchart of another example of an
organization chart construction method 500, performed in accordance
with some implementations. In various implementations, organization
chart construction method 500 may be used to identify individuals
to add or remove from an organizational chart, identify updated
information, update the organizational chart based on the
identified information, and generate a graphical depiction of the
updated organizational chart.
[0133] In FIG. 5, at block 502, a request to create or update an
organizational chart for an organization may be received. In
various implementations, the request may be issued by a user of the
database service and received by the database service provider. As
previously discussed, the user may have private contact data stored
in a virtual portion of a database system. The private contact data
may include contact information about several contacts. Each
contact may have an associated organization. For example, a
contact, such as an employee of a company, may be employed by
"Acme, Inc." Thus, the organization associated with the contact may
be the contact's employer, i.e. "Acme, Inc." In various
implementations, the user may wish to view additional information
about the contact's organization, such as which other employees are
employed by the organization, and how the organization is
structured. Accordingly, the user may issue a request to create or
update an organizational chart for the organization.
[0134] In various implementations, an existing organizational chart
may have already been created. The organizational chart may include
previously identified information about existing individuals. In
various implementations, the existing organizational chart may have
been previously generated by the database service provider as a
result of a previous request to view an organizational chart and
stored in a record in a database system. In such a situation, the
database service provider may retrieve the existing organizational
chart in response to receiving the request.
[0135] In various implementations, an existing organizational chart
might not have been previously generated. In such a situation,
there is no existing organizational chart generated by the database
service provider. Accordingly, the database service provider may
generate the entire organizational chart in response to receiving
the request at block 502.
[0136] FIG. 16 illustrates an example of an image 1600 of a user
interface that may be used to receive a request to create or update
an organizational chart for an organization, in accordance with
some implementations. In various implementations, image 1600 may
include data fields 1602, 1604, and 1606. Data field 1602 may
display various contact information associated with a contact or
entity included in a user's private contact data. In various
implementations, the contact information may include contact data
items retrieved from a record associated with the contact. In some
implementations, the contact data items displayed in data field
1602 may display information such as the contact's name, a picture
of the contact, the contact's occupational title, a business phone
number, and a business mailing address.
[0137] Data field 1604 may be in the form of an "Org Chart" tab,
which a user can click on using a pointing device such as a mouse
to display an organizational chart 1605 in this example. The
organizational chart 1605 is a partial view of a larger
organizational chart, which a user can access by clicking on the "1
Level to CEO" selection to navigate up the hierarchy or the "4 More
Levels" selection to navigate down the hierarchy. A computing
device configured to generate the user interface of image 1600
displays the graphical depiction of the organizational chart
associated with the contact or entity identified in data field
1602. In various implementations, a user may issue such a request
to obtain additional information about the organization with which
the contact or entity is associated and identify additional
contacts or entities based on the additional information.
Furthermore, the user may issue such a request if the user will
contribute additional information to the organizational chart, as
discussed in greater detail below with respect to FIG. 17. In this
instance, the user has requested to view a graphical depiction of
an organizational chart of an organization with which "Phil Marks"
is associated.
[0138] In various implementations, data field 1606 may display the
organizational chart 1605 for an organization associated with the
contact or entity identified by data field 1602. In this instance,
the contact "Phil Marks" is associated with the organization "Acme,
Inc." because he is the director of IT at Acme, Inc. Therefore, in
response to data field 1604 receiving a request to display an
organizational chart associated with Phil Marks, data field 1606
may display an organizational chart depicting a partial
presentation of the organizational hierarchy of Acme, Inc. In this
instance, an organizational chart has been previously generated by
the database service provider and stored in a record in a database
system. Thus, the database service provider may retrieve the record
from the database system and display the previously generated
organizational chart in data field 1606.
[0139] Returning to FIG. 5, at block 504, individuals that may be
added or removed from the organizational chart may be identified.
In various implementations, individuals may be identified by
searching contact data for individuals that may be associated with
the organization for which the graphical depiction of an
organizational chart was requested. In various implementations, an
individual associated with the organization may refer to an
individual that is employed by the organization, does business with
the organization, or has some interaction with the organization. As
previously discussed, the database service provider may store and
maintain shared contact data in a virtual portion of a database.
Thus, the database service provider may query the database and
search the shared contact data for individuals that are associated
with the organization for which the organizational chart has been
requested. For example, the shared contact data may include various
records that further include shared contact data items associated
with contacts. Thus, each record may be associated with a contact
and include a data field capable of storing a value that identifies
an organization associated with the contact, as well as a division
or group within the organization. For example, a record storing
contact data items for an employee of a corporation may include a
data field. The data field may store a data value that identifies
the corporation, such as Acme, Inc., that employs the employee, or
a team of which the employee is a member, such as the sales team.
In one example, the data value may be the name of the division or
group of the corporation, such as "Sales" or "Legal
Department".
[0140] In various implementations, the database service provider
may compare the data value stored in the data field (e.g., the
corporation's name) with the name of the organization associated
with the organizational chart. If the two values are the same, the
database service provider may determine that the contact (such as
the employee) is associated with the organization for which the
organizational chart has been requested and should be added to the
organizational chart. The database service provider may continue to
search the shared contact data to identify all individuals that
should be included in the organizational chart. In some
implementations, the database service provider may also perform a
similar search of the user's private contact data that may be
stored in a different virtual portion of the database system. The
results of the searches may be aggregated to form one set of
identified individuals that may be included in the organizational
chart.
[0141] In various implementations, individuals may be identified
based on a direct input from a user of a database service provided
by the database service provider. Thus, in some implementations, a
user may provide information that identifies an individual and
identifies a hierarchical relationship between individuals included
in an organizational chart. The database service provider may use
this information to determine whether or not the individuals should
be included in the organizational chart, and what hierarchical
relationship(s) should be associated with the identified
individual.
[0142] In various implementations, the user may provide the
previously described information in response to being presented
with a graphical depiction of an existing organizational chart.
Thus, as described in FIG. 16, data field 1606, the database
service provider may have previously generated a graphical
depiction of an organizational chart. The previously generated
graphical depiction of the organizational chart may have been
generated on data previously obtained from the user's private
contact data and shared contact data. In various implementations,
the previously generated graphical depiction may be presented to
the user in response to receiving the request to view an
organizational chart.
[0143] In response to being presented with the previously generated
graphical depiction, the user may determine that additional
individuals should be included in the organizational chart. For
example, a previously generated organizational chart may identify a
first contact as a distribution manager. The user may have recently
learned that a second contact now works for the first contact in a
subordinate capacity. In various implementations, the user may
select the first contact and manually input information identifying
the second contact as a subordinate employee.
[0144] FIG. 17 illustrates an example of an image 1700 of a user
interface that may be used to identify an individual to be added to
the organizational chart, in accordance with some implementations.
In various implementations, image 1700 may include data fields
1702, 1704, 1706, and 1708. Data field 1702 may be capable
receiving input contact information from the user that may be used
as the basis for identifying an individual to be added to the
organizational chart. For example, data field 1702 may receive a
name, title, and/or email address. The database service provider
may search the user's private contact data and shared contact data
for contacts or entities with similar or matching contact data
items. In this instance, the user has provided a name. In response
to receiving the name from the user, the database service provider
has searched the user's private contact data and shared contact
data for records storing contact data items for contacts or
entities having the same or similar names.
[0145] Data field 1704 may display contacts or entities from the
user's private contact data that have been identified as a result
of the search. In this instance, the user's private contact data
includes a contact with a name "Amy Williamson." Thus, contact data
for Amy Williamson is displayed in data field 1704. Displaying
additional contact data for contacts returned by the search enables
the user to determine whether or not the identified contact is the
correct contact to be included into the organizational chart. For
example, in addition to displaying Amy Williamson's name, her
occupational title may be also displayed. In this instance, the
user's private contact data does not have an occupational title for
Amy Williamson. Thus, data field 1704 displays "no title."
[0146] Data field 1706 may display contacts or entities from shared
contact data that have been identified as a result of the search.
In this instance, the shared contact data includes contacts with
the names "Amy Williams" and "Amy Wells." Thus contact data for Amy
Williams and Amy Wells may be displayed in data field 1706. In this
instance, the user has determined that Amy Wells is the correct
individual to include in the organizational chart based on the
contact information provided in data fields 1704 and 1706. In
various implementations, data fields 1704 and 1706 are both capable
of receiving an input that identifies a displayed contact as the
correct individual to include in the organizational chart. In this
instance, the user has indicated that Amy Wells is the correct
contact. Thus, data field 1706 may receive an input from the user,
such as a mouse click, that selects Amy Wells and indicates to the
database service provider that Amy Wells should be included in the
organizational chart.
[0147] In various implementations, data field 1708 may provide a
preview of what the organizational chart may look like after the
individual has been added. In this instance, data field 1708
indicates that an additional contact will be added as a subordinate
to "Phil Marks." Thus, in various implementations, data field 1708
provides the user with information that enables the user to verify
that the individual to be added to the organizational chart is
being added in the correct position within the organization's
hierarchy, and that hierarchical relationships associated with the
newly added individual are correct.
[0148] FIG. 18 illustrates an example of an image 1800 of a user
interface that may be used to confirm the addition of the
individual to the organizational chart, in accordance with some
implementations. In various implementations, image 1800 may include
data fields 1802 and 1804. As with data field 1708 of FIG. 17, data
field 1802 may display a graphical depiction of what the
organizational chart will look like after the individual identified
by the user is added to the organizational chart. In this instance,
the graphical depiction of the organizational chart will be updated
to include an additional contact subordinate to Phil Marks. In this
example, the additional contact is Amy Wells. In various
implementations, the user may determine that the updated
organizational chart is correct based on the information provided
by data field 1802.
[0149] Data field 1804 may be capable of receiving an input from
the user that indicates that the graphical depiction of the
organizational chart displayed in data field 1802 is correct.
Moreover, the input received by data field 1804 may indicate that
the identified contact should be added to the user's private
contact data. In this instance, the contact "Amy Wells" will be
added to the user's private contact data. Furthermore, the input
received by data field 1804 may indicate that the hierarchical
relationship identified by the user should be added to the shared
contact data. In various implementations, this information may be
included in the shared contact data in accordance with the method
described by contact data reconciliation method 300. Thus, other
users of database services provided by the database service
provider may access and utilize the identified hierarchical
relationship if they issue a request for a graphical depiction of
an organizational chart for this organization.
[0150] Returning to FIG. 5, at block 506, updated biographical
information for existing individuals may be identified. Thus, in
various implementations, if an existing organizational chart has
been previously generated, the database service provider may
identify updated biographical information for identified existing
individuals that were included in the previously generated
organizational chart. In some implementations, this may be
performed to ensure that the biographical information that is
displayed in the generated graphical depiction of the
organizational chart is the most recent and accurate biographical
information available.
[0151] In various implementations, the database service provider
may retrieve the updated biographical information from contact data
associated with the identified existing individuals. For example,
for each of the individuals included in the organizational chart,
there may be one or more records storing contact data. In various
implementations, the contact data may include contact data items
that store data values identifying biographical information
associated with the individuals. For example, the contact data
items may store a phone number and mailing address for an
individual. A database storing the contact data items may be
queried by the database service provider, and the most recent
contact data for the identified existing individuals may be
retrieved. In some implementations, the contact data may be shared
contact data that is aggregated from a plurality of entities. Thus,
the database service provider may search shared contact data to
retrieve updated biographical information for the identified
individuals.
[0152] In some implementations, if there is no previously generated
organizational chart, the database service provider may retrieve
all relevant biographical information associated with the
identified individuals from the contact data as discussed above and
use the retrieved data as the basis of a new organizational
chart.
[0153] In FIG. 5, at block 508, updated relationship information
for existing individuals may be identified. In various
implementations, relationship information may refer to information
that identifies a hierarchical relationship between two individuals
associated with an organization. Thus, relationship information may
be data or a data value that describes or provides information
about the hierarchical relationship. For example, a first
individual may be a marketing analyst. A second individual may be a
project manager who supervises the first individual. Thus, a
hierarchical relationship may exist between the two in which the
hierarchical relationship is that of supervisor/supervisee.
[0154] In various implementations, relationship information may be
stored in a data field included in a contact data record. For
example, a contact data record associated with a first individual
may have a "Reports to" data field. The "Reports to" data field may
store a value that identifies a second individual who the first
individual reports to. Furthermore, in some implementations, the
"Reports to" data field may also store a value that identifies a
type of hierarchical relationship between the first individual and
second individual, such as that of supervisor/supervisee. Thus, the
value(s) stored in the "Reports to" data field may identify
individuals included in a particular hierarchical relationship and
may identify the type of the hierarchical relationship (e.g.
whether or not the first individual is subordinate to the second
individual).
[0155] In various implementations, relationship information may be
inferred from a role or social role associated with an individual.
In various implementations, a role or social role may describe the
individual's interactions with other individuals. For example, if
an individual is responsible for making final decisions regarding
several sales projects or opportunities for an organization, that
individual may have an associated role of "decision maker." Because
such a role may be vital to business decisions related to the
organization's ordinary course of business and may directly
influence the actions of other individuals included in the
organization, it may be inferred that a "decision maker" occupies a
higher position within the organization than an individual who is
not a "decision maker." In this way, social roles may be used to
infer hierarchical relationships between individuals within the
organization. Such inferences may be utilized when other data, such
as a "Reports to" field, is not available to the database service
provider.
[0156] In some implementations a social role associated with an
individual may be determined by a machine algorithm which tracks
and analyzes actions taken by or otherwise involving an individual.
An example of such a machine algorithm may be Radian 6.TM. made
available by Salesforce.com.TM.. According to various
implementations, the machine algorithm may receive an input that
identifies an individual, such as a "social handle", and may return
metrics capable of identifying the individual's hierarchical
position. In some implementations, the metrics may include the
individual's social role and a summary of activities associated
with the identified social role. In various implementations, such
metrics may be determined by the machine algorithm based, at least
in part, on the individual's activity history. The activity history
may describe the individual's interactions with other individuals
or entities. In various implementations, actions taken by an
individual and interactions with other individuals or entities may
be stored as data objects in one or more records as the
individual's activity history. For example, an action in which an
individual changes the status of a case from "open" to "closed" may
be tracked by a database service provider. In response to the
change occurring, the database service provider may create a data
object storing one or more data values identifying the individual
and the action. The data object may be stored within the record, or
as a child object, as part of the individual's activity history.
According to some implementations, data objects included in the
individual's activity history may be retrieved from shared contact
data as well as other crowd sourced data. Thus, actions and
interactions involving the individual may be identified based on
data contributed to by several entities, such as other users of the
database service. The actions and interactions may be associated
with a social role based on designated associations between a type
of activity and a role. In various implementations, a designated
association may associate a pattern of activity with a particular
social role. For example, as previously discussed, activities such
as routinely making final decisions for business transactions may
be associated with the social role "decision maker".
[0157] As further discussed with reference to FIG. 19, relationship
information may also be inferred based on an individual's position
or level within an organization and/or an individual's department.
In various implementations, a machine algorithm may be used to
determine an individual's position or level and the individual's
department. The machine algorithm may retrieve information from
private and/or shared contact data, and it may retrieve information
from the individual's activity history. In some implementations,
the machine algorithm may query specific types of data fields of
contact records to retrieve information identifying the
individual's position and department. For example, data fields
storing data values identifying the individual's occupational
title, company name, and department may be queried. In some
implementations, if a data value identifying a department is not
available, the machine algorithm may infer the individual's
department based on the location of the individual's office. For
example, a company may have its corporate sales department located
in Austin, Tex. If an individual has a business address of Austin,
Tex., the machine algorithm may infer that the individual is part
of the corporate sales department. Similar inferences may be made
to determine a reporting structure associated with the individual's
organization.
[0158] According to various implementations, in response to
retrieving the information, the machine algorithm may group or
cluster the individuals according to their level and/or department.
For example, if several individuals have been identified as
included in a department and having a position or level of "staff",
they may be grouped according to their level and department. The
machine algorithm may infer a hierarchical relationship for all
individuals included in that particular level based on a known or
designated hierarchical relationship associated with that level.
For example, a staff manager may be identified as a manager or
supervisor of staff for a particular department. The machine
algorithm may infer that any individual within that department at
the position or level of "staff" is supervised by the staff
manager.
[0159] Returning to FIG. 5, at block 508, in some implementations,
if an existing organizational chart has been previously generated,
the database service provider may identify updated relationship
information for the identified existing individuals. Thus, the
database service provider may search contact data associated with
the identified existing individuals and retrieve relevant contact
information, such as values stored in "Reports to" data fields. In
various implementations, the database service provider may also
retrieve activity information associated with the existing
individuals. The activity information may be fed to a machine
algorithm to determine social roles that may be used to infer
additional relationship information. As previously discussed, a
machine algorithm, such as Radian 6.TM. made available by
Salesforce.com.TM. may be implemented to determine social roles. In
various implementations, the machine algorithm may determine social
roles based, at least in part, on activity information, such as an
individual's activity history.
[0160] In various implementations, if there is no previously
generated organizational chart, the database service provider may
retrieve all relevant relationship information associated with the
identified individuals from the contact data. As previously
discussed, the database service provider may search for and
retrieve relevant contact information, such as values stored in
"Reports to" data fields, and activity information that may be used
to infer additional relationship information.
[0161] In FIG. 5, at block 510, updated structural information for
the organization may be identified. In various implementations,
structural information may refer to information that describes how
an organization is organized. For example, structural information
may refer to different divisions within an organization, such as
departments or practice groups that may be included within the same
organization. Thus, a company may include various departments, such
as a sales department, a marketing department, an IT department, an
accounting department, and a human resources (HR) department.
Structural information for the company may include one or more data
values identifying each department within the company and how they
are related to each other. Each department may include its own
hierarchy of individuals as well as be part of a larger hierarchy
of departments. Thus, structural information associated with an
organization may provide information regarding how hierarchies
within an organization are divided and sub-divided. Structural
information may also identify hierarchical relationships between
divisions of an organization. For example, the structural
information may include a data value indicating that a first
department reports to a second department.
[0162] In various implementations, structural information may be
retrieved from contact data associated with individuals included in
the organization. In various implementations, a contact record may
store contact data items for an individual included in the
organization. The contact data items may include one or more data
values identifying a department associated with the individual. For
example, an employee who is a database manager may belong to an
Internet Technology (IT) department. Thus, a contact record may
include a contact data item storing a data value identifying the
employee's department as "IT." The database service provider may
search contact data associated with each individual included in the
organizational chart for similar contact data items. The database
service provider may then identify which departments exist within
an organization based on the identified contact data items.
[0163] Returning to FIG. 5, at block 510, in various
implementations, the database service provider may identify updated
structural information for the organization. As previously
discussed, the updated structural information may be retrieved from
data fields included in contact records for the individuals
included in the organization. Thus, the database service provider
may search contact records storing contact data for the individuals
identified at FIG. 5, block 504 for contact data items that
identify structural information about the organization. The
database service provider may aggregate this information and store
it as a separate record in a virtual portion of a database system
operated and maintained by the database service provider.
[0164] In FIG. 5, at block 512, the organizational chart may be
created or updated based on the identified information. Thus, the
information retrieved at blocks 504, 506, and 508 may be
incorporated into the organizational chart at block 512. In various
implementations, if the database service provider has not already
done so, the database service provider may determine whether or not
a previously generated organizational chart exists. In various
implementations, as discussed in greater detail below with regard
to FIG. 5, block 516, organizational charts may be stored in one or
more records in a virtual portion of a database system operated and
maintained by the database service provider. The database service
provider may search the virtual portion of the database system for
a record storing an organizational chart associated with the
organization.
[0165] In various implementations, the database service provider
may identify a record that stores an existing organizational chart
for the organization. If there is an existing organizational chart,
existing information may be replaced by the identified and
retrieved updated information. Thus, existing information already
stored in the identified record, such as a list of individuals
included in the organization for which the organizational chart has
been requested, and previously retrieved contact information
associated with the individuals, may be replaced by the newly
identified and retrieved information. In various implementations,
in response to identifying a record that stores an existing
organizational chart, the database service provider may create a
new record and store all relevant information in the new record as
a new organizational chart instead of updating the existing
organizational chart.
[0166] In various implementations, if there is no existing
organizational chart, the identified information may be used to
generate new record that includes a new organizational chart. Thus,
the database service provider may aggregate the information
identifying the individuals to be included in the organizational
chart, the biographical and relationship information associated
with the individuals, and the structural information associated
with the organization. The database service provider may generate a
new organizational chart for the organization based on the
aggregated information.
[0167] In FIG. 5, at block 514, a graphical depiction of the
updated organizational chart may be generated. In various
implementations, the graphical representation may be an image
capable of being displayed in a user interface of a computer
device. The graphical depiction of the updated organizational chart
may provide the user with various information about individuals
included in the organization, and hierarchical relationships
between the individuals included in the organization. For example,
a hierarchical relationship, such as a first contact reporting to a
second contact, may be depicted by a line or connection between the
first and second contact. The same may be true for all identified
hierarchical relationships associated the individuals included in
the graphical depiction of the organizational chart. Thus, the
graphical depiction may simultaneously display all identified
hierarchical relationships associated with the organization for
which the organizational chart has been requested.
[0168] Furthermore, the graphical depiction may arrange the
identified individuals into groups based on a hierarchical position
associated with each individual. In various implementations, a
hierarchical position associated with an individual may refer to a
position or level within a hierarchy of the organization that is
occupied by the individual. For example, a hierarchical position
may include all junior-level associates, all senior-level managers,
or all department directors. In various implementations, if several
individuals are at the same hierarchical position, such as trainee,
the several individuals may all be grouped into one level of a
hierarchical tree. Thus, grouping individuals according to a
position or level within a hierarchy may provide information about
indirect hierarchical relationships between individuals. An
indirect hierarchical relationship may be a hierarchical
relationship where a first individual does not directly report to a
second individual, but still occupies a subordinate or inferior
position to the second individual. For example, an entry level
sales person might not directly report to a regional sales manager,
but would be at a lower hierarchical position than the regional
sales manager.
[0169] In various implementations, the graphical depiction may
display various contact information for one or more individual(s)
included in the organizational chart. For example, the graphical
depiction of the organizational chart may include a data field for
each individual included in the organizational chart. The data
field may display information that identifies the individual and
provides contact information for the individual. For example, the
data field may be displayed as graphical icon representing the
individual. The icon may display a picture that has been retrieved
from a contact record storing contact data for the individual. The
icon may also display the individual's occupational title. The
occupational title may provide additional context or information
regarding the hierarchical relationship between the individual and
other individuals that he or she may report to.
[0170] FIG. 19 illustrates an example of an image 1900 of a user
interface that may be used to display a graphical depiction of an
updated organizational chart 1901 associated with an organization,
in accordance with some implementations. In various
implementations, image 1900 may include data fields 1902, 1904,
1906, 1908, 1910, and 1912. As with data field 1602 of FIG. 16,
data field 1902 may display various contact data items for a
contact or entity included in a user's private contact data. In
some implementations, the contact data items displayed in data
field 1902 may include the contact's name, a picture of the
contact, the contact's occupational title, a business phone number,
and a business mailing address.
[0171] In various implementations, data field 1904 may display a
graphical depiction of an updated organizational chart 1901 for an
organization associated with the contact identified in data field
1902. In this instance, data field 1904 displays an updated
organizational chart for "Acme, Inc.," which is the company that
employs the contact "Phil Marks" as identified by data field 1902.
In this instance, the updated organizational chart 1901 displayed
in data field 1904 has been updated to include an additional
individual, "Amy Wells" in this example.
[0172] In various implementations, organizational chart 1901 may be
arranged to display individuals included in an organization
according to their positions within the hierarchy of an
organization. Accordingly, data field 1904 may include data fields
1906, 1908, 1910, and 1912. In various implementations, data field
1906 may display the next highest level in the hierarchy of the
organization with respect to the contact identified in data field
1902. In this instance, data field 1906 displays contact
information for "Darren Mack" who is the CIO of the organization
and directly supervises "Phil Marks," who is the contact identified
by data field 1902 and the contact for whom the graphical depiction
of the organizational chart was originally requested.
[0173] In various implementations, data field 1908 may include
information for all individuals that are subordinate to and
directly report to the individuals identified in data field 1906.
In this instance, the individuals "Billie Willis," "Jill Garza,"
"Phil Marks," "Raymond Myers," and "Rose Anders" all directly
report to Darren Mack. Thus, contact information and a hierarchical
relationship for these individuals is displayed in data field
1908.
[0174] In various implementations, data field 1910 may include
information for all individuals that are subordinate to and
directly report to one or more of the individuals identified in
data field 1908. In this instance, the individuals "Amy Wells,"
"Sheila Collins," "William Johnson," and "Ben Smith" all directly
report to Phil Marks. Thus, contact information and hierarchical
relationship information for these individuals is displayed in data
field 1910. In this way, data fields 1906, 1908, and 1910 may each
display contact information for individuals organized based on
their position within a hierarchy of the organization and based on
their hierarchical relationships with each other.
[0175] In various implementations, data field 1912 may provide a
link to additional levels in the hierarchy of the organization that
may exist but have not been displayed in data field 1904. In some
implementations, displaying various levels of the hierarchy of the
organization may be omitted to simplify the graphical depiction of
the organizational chart. Thus, in various implementations, the
graphical depiction of the organizational chart may be constrained
based on a number of intermediate connections between the contact
identified in data field 1902 and an individual included in the
organizational chart. In this instance, the graphical depiction of
the organizational chart has been requested for "Phil Marks." Thus,
a graphical depiction of the organizational chart has been
generated that includes levels in the organizational hierarchy
immediately above and below Phil Marks. However, other levels in
the hierarchy might not be as relevant to the user's inquiry. In
various implementations, the user might only be interested in Phil
Marks's position within the organization, and not the organization
as a whole. Thus, to simplify the graphical depiction of the
organizational chart, less relevant levels of the organizational
hierarchy may be omitted from the graphical depiction of the
organizational chart, but remain available upon request (i.e.
providing an input to a data field, such as data field 1912).
[0176] Returning to FIG. 5, at block 516, the updated
organizational chart may be stored. The updated organizational
chart may be stored in a record in a virtual portion of the
database system associated with the user. Thus, the updated
organizational chart may be stored and retrieved by the user at a
subsequent time. In some implementations, the updated
organizational chart may be stored in a shared virtual portion of
the database system. Thus, the updated organizational chart may be
added to other crowd sourced information maintained by the database
service provider. In some implementations, the updated
organizational chart may be stored in the same virtual portion of a
database system that stores the user's private contact data. In
various implementations, the updated organizational chart may be
stored locally at a computing system operated by the user. When
stored locally, the user may access and retrieve the updated
organizational chart when a connection, such as a network
connection, with the database service provider is not present.
[0177] FIG. 20A shows a system diagram 2000 illustrating
architectural components of an on-demand service environment that
may be used to implement a contact data unification method, in
accordance with some implementations.
[0178] A client machine located in the cloud 2004 (or Internet) may
communicate with the on-demand service environment via one or more
edge routers 2008 and 2012. The edge routers may communicate with
one or more core switches 2020 and 2024 via firewall 2016. The core
switches may communicate with a load balancer 2028, which may
distribute server load over different pods, such as the pods 2040
and 2044. The pods 2040 and 2044, which may each include one or
more servers and/or other computing resources, may perform data
processing and other operations used to provide on-demand services.
Communication with the pods may be conducted via pod switches 2032
and 2036. Components of the on-demand service environment may
communicate with a database storage system 2056 via a database
firewall 2048 and a database switch 2052.
[0179] As shown in FIGS. 20A and 20B, accessing an on-demand
service environment may involve communications transmitted among a
variety of different hardware and/or software components. Further,
the on-demand service environment 2000 is a simplified
representation of an actual on-demand service environment. For
example, while only one or two devices of each type are shown in
FIGS. 20A and 20B, some embodiments of an on-demand service
environment may include anywhere from one to many devices of each
type. Also, the on-demand service environment need not include each
device shown in FIGS. 20A and 20B, or may include additional
devices not shown in FIGS. 20A and 20B.
[0180] Moreover, one or more of the devices in the on-demand
service environment 2000 may be implemented on the same physical
device or on different hardware. Some devices may be implemented
using hardware or a combination of hardware and software. Thus,
terms such as "data processing apparatus," "machine," "server" and
"device" as used herein are not limited to a single hardware
device, but rather include any hardware and software configured to
provide the described functionality.
[0181] The cloud 2004 is intended to refer to a data network or
plurality of data networks, often including the Internet. Client
machines located in the cloud 2004 may communicate with the
on-demand service environment to access services provided by the
on-demand service environment. For example, client machines may
access the on-demand service environment to retrieve, store, edit,
and/or process information.
[0182] In some embodiments, the edge routers 2008 and 2012 route
packets between the cloud 2004 and other components of the
on-demand service environment 2000. The edge routers 2008 and 2012
may employ the Border Gateway Protocol (BGP). The BGP is the core
routing protocol of the Internet. The edge routers 2008 and 2012
may maintain a table of IP networks or `prefixes` which designate
network reachability among autonomous systems on the Internet.
[0183] In one or more embodiments, the firewall 2016 may protect
the inner components of the on-demand service environment 2000 from
Internet traffic. The firewall 2016 may block, permit, or deny
access to the inner components of the on-demand service environment
2000 based upon a set of rules and other criteria. The firewall
2016 may act as one or more of a packet filter, an application
gateway, a stateful filter, a proxy server, or any other type of
firewall.
[0184] In some embodiments, the core switches 2020 and 2024 are
high-capacity switches that transfer packets within the on-demand
service environment 2000. The core switches 2020 and 2024 may be
configured as network bridges that quickly route data between
different components within the on-demand service environment. In
some embodiments, the use of two or more core switches 2020 and
2024 may provide redundancy and/or reduced latency.
[0185] In some embodiments, the pods 2040 and 2044 may perform the
core data processing and service functions provided by the
on-demand service environment. Each pod may include various types
of hardware and/or software computing resources. An example of the
pod architecture is discussed in greater detail with reference to
FIG. 20B.
[0186] In some embodiments, communication between the pods 2040 and
2044 may be conducted via the pod switches 2032 and 2036. The pod
switches 2032 and 2036 may facilitate communication between the
pods 2040 and 2044 and client machines located in the cloud 2004,
for example via core switches 2020 and 2024. Also, the pod switches
2032 and 2036 may facilitate communication between the pods 2040
and 2044 and the database storage 2056.
[0187] In some embodiments, the load balancer 2028 may distribute
workload between the pods 2040 and 2044. Balancing the on-demand
service requests between the pods may assist in improving the use
of resources, increasing throughput, reducing response times,
and/or reducing overhead. The load balancer 2028 may include
multilayer switches to analyze and forward traffic.
[0188] In some embodiments, access to the database storage 2056 may
be guarded by a database firewall 2048. The database firewall 2048
may act as a computer application firewall operating at the
database application layer of a protocol stack. The database
firewall 2048 may protect the database storage 2056 from
application attacks such as structure query language (SQL)
injection, database rootkits, and unauthorized information
disclosure.
[0189] In some embodiments, the database firewall 2048 may include
a host using one or more forms of reverse proxy services to proxy
traffic before passing it to a gateway router. The database
firewall 2048 may inspect the contents of database traffic and
block certain content or database requests. The database firewall
2048 may work on the SQL application level atop the TCP/IP stack,
managing applications' connection to the database or SQL management
interfaces as well as intercepting and enforcing packets traveling
to or from a database network or application interface.
[0190] In some embodiments, communication with the database storage
system 2056 may be conducted via the database switch 2052. The
multi-tenant database system 2056 may include more than one
hardware and/or software components for handling database queries.
Accordingly, the database switch 2052 may direct database queries
transmitted by other components of the on-demand service
environment (e.g., the pods 2040 and 2044) to the correct
components within the database storage system 2056.
[0191] In some embodiments, the database storage system 2056 is an
on-demand database system shared by many different organizations.
The on-demand database system may employ a multi-tenant approach, a
virtualized approach, or any other type of database approach. An
on-demand database system is discussed in greater detail with
reference to FIGS. 21 and 22.
[0192] FIG. 20B shows a system diagram further illustrating
architectural components of an on-demand service environment that
may be used to implement a contact data unification method, in
accordance with some implementations.
[0193] In some embodiments, each pod may include a variety of
servers and/or other systems. The pod 2044 includes one or more
content batch servers 2064, content search servers 2068, query
servers 2072, file force servers 2076, access control system (ACS)
servers 2080, batch servers 2084, and app servers 2088. Also, the
pod 2044 includes database instances 2090, quick file systems (QFS)
2092, and indexers 2094. In one or more embodiments, some or all
communication between the servers in the pod 2044 may be
transmitted via the switch 2036.
[0194] In some embodiments, the application servers 2088 may
include a hardware and/or software framework dedicated to the
execution of procedures (e.g., programs, routines, scripts) for
supporting the construction of applications provided by the
on-demand service environment 2000 via the pod 2044. Some such
procedures may include operations for providing the services
described herein.
[0195] The content batch servers 2064 may requests internal to the
pod. These requests may be long-running and/or not tied to a
particular customer. For example, the content batch servers 2064
may handle requests related to log mining, cleanup work, and
maintenance tasks.
[0196] The content search servers 2068 may provide query and
indexer functions. For example, the functions provided by the
content search servers 2068 may allow users to search through
content stored in the on-demand service environment.
[0197] The Fileforce servers 2076 may manage requests information
stored in the Fileforce storage 2078. The Fileforce storage 2078
may store information such as documents, images, and basic large
objects (BLOBs). By managing requests for information using the
Fileforce servers 2076, the image footprint on the database may be
reduced.
[0198] The query servers 2072 may be used to retrieve information
from one or more file systems. For example, the query system 2072
may receive requests for information from the app servers 2088 and
then transmit information queries to the NFS 2096 located outside
the pod.
[0199] The pod 2044 may share a database instance 2090 configured
as a multi-tenant environment in which different organizations
share access to the same database. Additionally, services rendered
by the pod 2044 may require various hardware and/or software
resources. In some embodiments, the ACS servers 2080 may control
access to data, hardware resources, or software resources.
[0200] In some embodiments, the batch servers 2084 may process
batch jobs, which are used to run tasks at specified times. Thus,
the batch servers 2084 may transmit instructions to other servers,
such as the app servers 2088, to trigger the batch jobs.
[0201] In some embodiments, the QFS 2092 may be an open source file
system available from Sun Microsystems.RTM. of Santa Clara, Calif.
The QFS may serve as a rapid-access file system for storing and
accessing information available within the pod 2044. The QFS 2092
may support some volume management capabilities, allowing many
disks to be grouped together into a file system. File system
metadata can be kept on a separate set of disks, which may be
useful for streaming applications where long disk seeks cannot be
tolerated. Thus, the QFS system may communicate with one or more
content search servers 2068 and/or indexers 2094 to identify,
retrieve, move, and/or update data stored in the network file
systems 2096 and/or other storage systems.
[0202] In some embodiments, one or more query servers 2072 may
communicate with the NFS 2096 to retrieve and/or update information
stored outside of the pod 2044. The NFS 2096 may allow servers
located in the pod 2044 to access information to access files over
a network in a manner similar to how local storage is accessed.
[0203] In some embodiments, queries from the query servers 2022 may
be transmitted to the NFS 2096 via the load balancer 2020, which
may distribute resource requests over various resources available
in the on-demand service environment. The NFS 2096 may also
communicate with the QFS 2092 to update the information stored on
the NFS 2096 and/or to provide information to the QFS 2092 for use
by servers located within the pod 2044.
[0204] In some embodiments, the pod may include one or more
database instances 2090. The database instance 2090 may transmit
information to the QFS 2092. When information is transmitted to the
QFS, it may be available for use by servers within the pod 2044
without requiring an additional database call.
[0205] In some embodiments, database information may be transmitted
to the indexer 2094. Indexer 2094 may provide an index of
information available in the database 2090 and/or QFS 2092. The
index information may be provided to file force servers 2076 and/or
the QFS 2092.
[0206] FIG. 21 shows a system diagram 2110 illustrating the
architecture of a multitenant database environment, in accordance
with some implementations.
[0207] Environment 2110 includes an on-demand database service
2116. User system 2112 may be any machine or system that is used by
a user to access a database user system. For example, any of user
systems 2112 can be a handheld computing device, a mobile phone, a
laptop computer, a work station, and/or a network of computing
devices. As illustrated in FIGS. 21 and 22, user systems 2112 might
interact via a network 2114 with the on-demand database service
2116.
[0208] An on-demand database service, such as system 2116, is a
database system that is made available to outside users that do not
need to necessarily be concerned with building and/or maintaining
the database system, but instead may be available for their use
when the users need the database system (e.g., on the demand of the
users). Some on-demand database services may store information from
one or more tenants stored into tables of a common database image
to form a multi-tenant database system (MTS).
[0209] Accordingly, "on-demand database service 2116" and "system
2116" will be used interchangeably herein. A database image may
include one or more database objects. A relational database
management system (RDBMS) or the equivalent may execute storage and
retrieval of information against the database object(s).
Application platform 2118 may be a framework that allows the
applications of system 2116 to run, such as the hardware and/or
software, e.g., the operating system. In an embodiment, on-demand
database service 2116 may include an application platform 2118 that
enables creation, managing and executing one or more applications
developed by the provider of the on-demand database service, users
accessing the on-demand database service via user systems 2112, or
third party application developers accessing the on-demand database
service via user systems 2112.
[0210] One arrangement for elements of system 2116 is shown in FIG.
21, including a network interface 2120, application platform 2118,
tenant data storage 2122 for tenant data 2123, system data storage
2124 for system data 2125 accessible to system 2116 and possibly
multiple tenants, program code 2126 for implementing various
functions of system 2116, and a process space 2128 for executing
MTS system processes and tenant-specific processes, such as running
applications as part of an application hosting service. Additional
processes that may execute on system 2116 include database indexing
processes.
[0211] The users of user systems 2112 may differ in their
respective capacities, and the capacity of a particular user system
2112 might be entirely determined by permissions (permission
levels) for the current user. For example, where a call center
agent is using a particular user system 2112 to interact with
system 2116, the user system 2112 has the capacities allotted to
that call center agent. However, while an administrator is using
that user system to interact with system 2116, that user system has
the capacities allotted to that administrator. In systems with a
hierarchical role model, users at one permission level may have
access to applications, data, and database information accessible
by a lower permission level user, but may not have access to
certain applications, database information, and data accessible by
a user at a higher permission level. Thus, different users may have
different capabilities with regard to accessing and modifying
application and database information, depending on a user's
security or permission level.
[0212] Network 2114 is any network or combination of networks of
devices that communicate with one another. For example, network
2114 can be any one or any combination of a LAN (local area
network), WAN (wide area network), telephone network, wireless
network, point-to-point network, star network, token ring network,
hub network, or other appropriate configuration. As the most common
type of computer network in current use is a TCP/IP (Transfer
Control Protocol and Internet Protocol) network (e.g., the
Internet), that network will be used in many of the examples
herein. However, it should be understood that the networks used in
some embodiments are not so limited, although TCP/IP is a
frequently implemented protocol.
[0213] User systems 2112 might communicate with system 2116 using
TCP/IP and, at a higher network level, use other common Internet
protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an
example where HTTP is used, user system 2112 might include an HTTP
client commonly referred to as a "browser" for sending and
receiving HTTP messages to and from an HTTP server at system 2116.
Such an HTTP server might be implemented as the sole network
interface between system 2116 and network 2114, but other
techniques might be used as well or instead. In some
implementations, the interface between system 2116 and network 2114
includes load sharing functionality, such as round-robin HTTP
request distributors to balance loads and distribute incoming HTTP
requests evenly over a plurality of servers. At least as for the
users that are accessing that server, each of the plurality of
servers has access to the MTS' data; however, other alternative
configurations may be used instead.
[0214] In one embodiment, system 2116, shown in FIG. 21, implements
a web-based customer relationship management (CRM) system. For
example, in one embodiment, system 2116 includes application
servers configured to implement and execute CRM software
applications as well as provide related data, code, forms, web
pages and other information to and from user systems 2112 and to
store to, and retrieve from, a database system related data,
objects, and Webpage content. With a multi-tenant system, data for
multiple tenants may be stored in the same physical database
object, however, tenant data typically is arranged so that data of
one tenant is kept logically separate from that of other tenants so
that one tenant does not have access to another tenant's data,
unless such data is expressly shared. In certain embodiments,
system 2116 implements applications other than, or in addition to,
a CRM application. For example, system 2116 may provide tenant
access to multiple hosted (standard and custom) applications. User
(or third party developer) applications, which may or may not
include CRM, may be supported by the application platform 2118,
which manages creation, storage of the applications into one or
more database objects and executing of the applications in a
virtual machine in the process space of the system 2116.
[0215] Each user system 2112 could include a desktop personal
computer, workstation, laptop, PDA, cell phone, or any wireless
access protocol (WAP) enabled device or any other computing device
capable of interfacing directly or indirectly to the Internet or
other network connection. User system 2112 typically runs an HTTP
client, e.g., a browsing program, such as Microsoft's Internet
Explorer.RTM. browser, Mozilla's Firefox.RTM. browser, Opera's
browser, or a WAP-enabled browser in the case of a cell phone, PDA
or other wireless device, or the like, allowing a user (e.g.,
subscriber of the multi-tenant database system) of user system 2112
to access, process and view information, pages and applications
available to it from system 2116 over network 2114.
[0216] Each user system 2112 also typically includes one or more
user interface devices, such as a keyboard, a mouse, trackball,
touch pad, touch screen, pen or the like, for interacting with a
graphical user interface (GUI) provided by the browser on a display
(e.g., a monitor screen, LCD display, etc.) in conjunction with
pages, forms, applications and other information provided by system
2116 or other systems or servers. For example, the user interface
device can be used to access data and applications hosted by system
2116, and to perform searches on stored data, and otherwise allow a
user to interact with various GUI pages that may be presented to a
user. As discussed above, embodiments are suitable for use with the
Internet, which refers to a specific global internetwork of
networks. However, it should be understood that other networks can
be used instead of the Internet, such as an intranet, an extranet,
a virtual private network (VPN), a non-TCP/IP based network, any
LAN or WAN or the like.
[0217] According to one embodiment, each user system 2112 and all
of its components are operator configurable using applications,
such as a browser, including computer code run using a central
processing unit such as an Intel Pentium.RTM. processor or the
like. Similarly, system 2116 (and additional instances of an MTS,
where more than one is present) and all of their components might
be operator configurable using application(s) including computer
code to run using a central processing unit such as processor
system 2117, which may include an Intel Pentium.RTM. processor or
the like, and/or multiple processor units.
[0218] A computer program product embodiment includes a
machine-readable storage medium (media) having instructions stored
thereon/in which can be used to program a computer to perform any
of the processes of the embodiments described herein. Computer code
for operating and configuring system 2116 to intercommunicate and
to process web pages, applications and other data and media content
as described herein are preferably downloaded and stored on a hard
disk, but the entire program code, or portions thereof, may also be
stored in any other volatile or non-volatile memory medium or
device, such as a ROM or RAM, or provided on any media capable of
storing program code, such as any type of rotating media including
floppy disks, optical discs, digital versatile disk (DVD), compact
disk (CD), microdrive, and magneto-optical disks, and magnetic or
optical cards, nanosystems (including molecular memory ICs), or any
type of media or device suitable for storing instructions and/or
data. Additionally, the entire program code, or portions thereof,
may be transmitted and downloaded from a software source over a
transmission medium, e.g., over the Internet, or from another
server, or transmitted over any other conventional network
connection (e.g., extranet, VPN, LAN, etc.) using any communication
medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.).
It will also be appreciated that computer code for implementing
embodiments can be implemented in any programming language that can
be executed on a client system and/or server or server system such
as, for example, C, C++, HTML, any other markup language, Java.TM.,
JavaScript.RTM., ActiveX.RTM., any other scripting language, such
as VBScript, and many other programming languages as are well known
may be used. (Java.TM. is a trademark of Sun Microsystems.RTM.,
Inc.).
[0219] According to one embodiment, each system 2116 is configured
to provide web pages, forms, applications, data and media content
to user (client) systems 2112 to support the access by user systems
2112 as tenants of system 2116. As such, system 2116 provides
security mechanisms to keep each tenant's data separate unless the
data is shared. If more than one MTS is used, they may be located
in close proximity to one another (e.g., in a server farm located
in a single building or campus), or they may be distributed at
locations remote from one another (e.g., one or more servers
located in city A and one or more servers located in city B). As
used herein, each MTS could include logically and/or physically
connected servers distributed locally or across one or more
geographic locations. Additionally, the term "server" is meant to
include a computer system, including processing hardware and
process space(s), and an associated storage system and database
application (e.g., OODBMS or RDBMS) as is well known in the
art.
[0220] It should also be understood that "server system" and
"server" are often used interchangeably herein. Similarly, the
database object described herein can be implemented as single
databases, a distributed database, a collection of distributed
databases, a database with redundant online or offline backups or
other redundancies, etc., and might include a distributed database
or storage network and associated processing intelligence.
[0221] FIG. 22 shows a system diagram 2110 further illustrating the
architecture of a multitenant database environment, in accordance
with some implementations. FIG. 22 shows that user system 2112 may
include processor system 2112A, memory system 2112B, input system
2112C, and output system 2112D. FIG. 22 shows network 2114 and
system 2116. FIG. 22 also shows that system 2116 may include tenant
data storage 2122, tenant data 2123, system data storage 2124,
system data 2125, User Interface (UI) 2230, Application Program
Interface (API) 2232, PL/SOQL 2234, save routines 2236, application
setup mechanism 2238, applications servers 22001-2400N, system
process space 2202, tenant process spaces 2204, tenant management
process space 2210, tenant storage area 2212, user storage 2214,
and application metadata 2216. In other embodiments, environment
2110 may not have the same elements as those listed above and/or
may have other elements instead of, or in addition to, those listed
above.
[0222] User system 2112, network 2114, system 2116, tenant data
storage 2122, and system data storage 2124 were discussed above in
FIG. 21. Regarding user system 2112, processor system 2112A may be
any combination of processors. Memory system 2112B may be any
combination of one or more memory devices, short term, and/or long
term memory. Input system 2112C may be any combination of input
devices, such as keyboards, mice, trackballs, scanners, cameras,
and/or interfaces to networks. Output system 2112D may be any
combination of output devices, such as monitors, printers, and/or
interfaces to networks. As shown by FIG. 22, system 2116 may
include a network interface 2120 (of FIG. 21) implemented as a set
of HTTP application servers 2200, an application platform 2118,
tenant data storage 2122, and system data storage 2124. Also shown
is system process space 2202, including individual tenant process
spaces 2204 and a tenant management process space 2210. Each
application server 2200 may be configured to tenant data storage
2122 and the tenant data 2123 therein, and system data storage 2124
and the system data 2125 therein to serve requests of user systems
2112. The tenant data 2123 might be divided into individual tenant
storage areas 2212, which can be either a physical arrangement
and/or a logical arrangement of data. Within each tenant storage
area 2212, user storage 2214 and application metadata 2216 might be
similarly allocated for each user. For example, a copy of a user's
most recently used (MRU) items might be stored to user storage
2214. Similarly, a copy of MRU items for an entire organization
that is a tenant might be stored to tenant storage area 2212. A UI
2230 provides a user interface and an API 2232 provides an
application programmer interface to system 2116 resident processes
to users and/or developers at user systems 2112. The tenant data
and the system data may be stored in various databases, such as
Oracle.TM. databases.
[0223] Application platform 2118 includes an application setup
mechanism 2238 that supports application developers' creation and
management of applications, which may be saved as metadata into
tenant data storage 2122 by save routines 2236 for execution by
subscribers as tenant process spaces 2204 managed by tenant
management process 2210 for example. Invocations to such
applications may be coded using PL/SOQL 34 that provides a
programming language style interface extension to API 2232. A
detailed description of some PL/SOQL language embodiments is
discussed in commonly assigned U.S. Pat. No. 7,730,478, titled
METHOD AND SYSTEM FOR ALLOWING ACCESS TO DEVELOPED APPLICATIONS VIA
A MULTI-TENANT ON-DEMAND DATABASE SERVICE, by Craig Weissman, filed
Sep. 20, 2007, which is hereby incorporated by reference in its
entirety and for all purposes. Invocations to applications may be
detected by system processes, which manage retrieving application
metadata 2216 for the subscriber making the invocation and
executing the metadata as an application in a virtual machine.
[0224] Each application server 2200 may be communicably coupled to
database systems, e.g., having access to system data 2125 and
tenant data 2123, via a different network connection. For example,
one application server 22001 might be coupled via the network 2114
(e.g., the Internet), another application server 2200N-1 might be
coupled via a direct network link, and another application server
2200N might be coupled by yet a different network connection.
Transfer Control Protocol and Internet Protocol (TCP/IP) are
typical protocols for communicating between application servers
2200 and the database system. However, other transport protocols
may be used to optimize the system depending on the network
interconnect used.
[0225] In certain embodiments, each application server 2200 is
configured to handle requests for any user associated with any
organization that is a tenant. Because it is desirable to be able
to add and remove application servers from the server pool at any
time for any reason, there is preferably no server affinity for a
user and/or organization to a specific application server 2200. In
one embodiment, therefore, an interface system implementing a load
balancing function (e.g., an F5 Big-IP load balancer) is
communicably coupled between the application servers 2200 and the
user systems 2112 to distribute requests to the application servers
2200. In one embodiment, the load balancer uses a least connections
algorithm to route user requests to the application servers 2200.
Other examples of load balancing algorithms, such as round robin
and observed response time, also can be used. For example, in
certain embodiments, three consecutive requests from the same user
could hit three different application servers 2200, and three
requests from different users could hit the same application server
2200. In this manner, system 2116 is multi-tenant, wherein system
2116 handles storage of, and access to, different objects, data and
applications across disparate users and organizations.
[0226] As an example of storage, one tenant might be a company that
employs a sales force where each call center agent uses system 2116
to manage their sales process. Thus, a user might maintain contact
data, leads data, customer follow-up data, performance data, goals
and progress data, etc., all applicable to that user's personal
sales process (e.g., in tenant data storage 2122). In an example of
a MTS arrangement, since all of the data and the applications to
access, view, modify, report, transmit, calculate, etc., can be
maintained and accessed by a user system having nothing more than
network access, the user can manage his or her sales efforts and
cycles from any of many different user systems. For example, if a
call center agent is visiting a customer and the customer has
Internet access in their lobby, the call center agent can obtain
critical updates as to that customer while waiting for the customer
to arrive in the lobby.
[0227] While each user's data might be separate from other users'
data regardless of the employers of each user, some data might be
organization-wide data shared or accessible by a plurality of users
or all of the users for a given organization that is a tenant.
Thus, there might be some data structures managed by system 2116
that are allocated at the tenant level while other data structures
might be managed at the user level. Because an MTS might support
multiple tenants including possible competitors, the MTS should
have security protocols that keep data, applications, and
application use separate. Also, because many tenants may opt for
access to an MTS rather than maintain their own system, redundancy,
up-time, and backup are additional functions that may be
implemented in the MTS. In addition to user-specific data and
tenant specific data, system 2116 might also maintain system level
data usable by multiple tenants or other data. Such system level
data might include industry reports, news, postings, and the like
that are sharable among tenants.
[0228] In certain embodiments, user systems 2112 (which may be
client machines/systems) communicate with application servers 2200
to request and update system-level and tenant-level data from
system 2116 that may require sending one or more queries to tenant
data storage 2122 and/or system data storage 2124. System 2116
(e.g., an application server 2200 in system 2116) automatically
generates one or more SQL statements (e.g., SQL queries) that are
designed to access the desired information. System data storage
2124 may generate query plans to access the requested data from the
database.
[0229] Each database can generally be viewed as a collection of
objects, such as a set of logical tables, containing data fitted
into predefined categories. A "table" is one representation of a
data object, and may be used herein to simplify the conceptual
description of objects and custom objects according to some
embodiments. It should be understood that "table" and "object" may
be used interchangeably herein. Each table generally contains one
or more data categories logically arranged as columns or fields in
a viewable schema. Each row or record of a table contains an
instance of data for each category defined by the fields. For
example, a CRM database may include a table that describes a
customer with fields for basic contact information such as name,
address, phone number, fax number, etc. Another table might
describe a purchase order, including fields for information such as
customer, product, sale price, date, etc. In some multi-tenant
database systems, standard entity tables might be provided for use
by all tenants. For CRM database applications, such standard
entities might include tables for contact, lead, and opportunity
data, each containing pre-defined fields. It should be understood
that the word "entity" may also be used interchangeably herein with
"object" and "table".
[0230] In some multi-tenant database systems, tenants may be
allowed to create and store custom objects, or they may be allowed
to customize standard entities or objects, for example by creating
custom fields for standard objects, including custom index fields.
U.S. Pat. No. 7,779,039, titled CUSTOM ENTITIES AND FIELDS IN A
MULTI-TENANT DATABASE SYSTEM, by Weissman, et al., and which is
hereby incorporated by reference in its entirety and for all
purposes, teaches systems and methods for creating custom objects
as well as customizing standard objects in a multi-tenant database
system. In some embodiments, for example, all custom entity data
rows are stored in a single multi-tenant physical table, which may
contain multiple logical tables per organization. In some
embodiments, multiple "tables" for a single customer may actually
be stored in one large table and/or in the same table as the data
of other customers.
[0231] These and other aspects of the disclosure may be implemented
by various types of hardware, software, firmware, etc. For example,
some features of the disclosure may be implemented, at least in
part, by machine-readable media that include program instructions,
state information, etc., for performing various operations
described herein. Examples of program instructions include both
machine code, such as produced by a compiler, and files containing
higher-level code that may be executed by the computer using an
interpreter. Examples of machine-readable media include, but are
not limited to, magnetic media such as hard disks, floppy disks,
and magnetic tape; optical media such as CD-ROM disks;
magneto-optical media; and hardware devices that are specially
configured to store and perform program instructions, such as
read-only memory devices ("ROM") and random access memory
("RAM").
[0232] While one or more implementations and techniques are
described with reference to an embodiment in which a service cloud
console is implemented in a system having an application server
providing a front end for an on-demand database service capable of
supporting multiple tenants, the one or more implementations and
techniques are not limited to multi-tenant databases nor deployment
on application servers. Embodiments may be practiced using other
database architectures, i.e., ORACLE.RTM., DB2.RTM. by IBM and the
like without departing from the scope of the embodiments
claimed.
[0233] Any of the above embodiments may be used alone or together
with one another in any combination. Although various embodiments
may have been motivated by various deficiencies with the prior art,
which may be discussed or alluded to in one or more places in the
specification, the embodiments do not necessarily address any of
these deficiencies. In other words, different embodiments may
address different deficiencies that may be discussed in the
specification. Some embodiments may only partially address some
deficiencies or just one deficiency that may be discussed in the
specification, and some embodiments may not address any of these
deficiencies.
[0234] While various embodiments have been described herein, it
should be understood that they have been presented by way of
example only, and not limitation. Thus, the breadth and scope of
the present application should not be limited by any of the
embodiments described herein, but should be defined only in
accordance with the following and later-submitted claims and their
equivalents.
* * * * *