Other than the Data Import, DataLoader and Salesforce Data Loader Command Line Interface Tool, which are Provided by Salesforce.com, which as per the project requirement can be used. Few of the techniques which i thought will help to automate the data Import process, are described below:
1. Automated Push Approach: Automated Push Approach will have a any lanugaue Window Service application running on the server machine outside of the Salesforce Environment. This Window Service will call Salesforce Data Loader Command Line Interface Tool to upload data into Salesforce.com object(s).
2. Automated Pull Approach: Cloud Job can be created and scheduled inside the Salesfoce App. object. Implicitly Cloud Job will call an External Web Service or Application. This External Web Service or Application will be outside the Cloud Environment and will be hosted on Remote Server. Scheduler will import the data into Salesfoce.com App.
3. Http Request / Response: Can create a Http Request to the FTP / Remote server. Can handle the response using either of HttpRequest and HttpResponse Apex Class
4. Cloud Approach: A User Interface will have “Import Data” functionality in Cloud Application, where user can browse data file and upload which will trigger data import into Cloud Application.
Hope this approaches help in automating data into Salesforce.com for Standard or Custom objects.
Sunday, January 30, 2011
Sunday, January 23, 2011
Cloud2
Cloud2 launched in April of 2010. More emphasis is intercation with the Customer by Social Media channels, wherease the traditional enterprise data model is disconnected from the conversation with the customer.
Salesforce.com’s Cloud 2 allows your organization to bridge the divide and tap into the dialogues occurring in these new social channels. Cloud 2 is about collaboration and making the Salesforce.com platform “social” with apps like Chatter. For example: If your comapny product user is struck with unrelated problem, and instead of calling company call center or search website of the company, user searches for the relevant solution on facebook, twitter, bing etc. social media sites. This kind of situations gave birth to Cloud2 by Salesforce.com.
It means that you need to enable your knowledge base to be available to be scraped, spidered and searched by the search engines like Google so that they can be indexed, and thus found by your customers. In Nutshell you never know where your company discussion (Good or Bad) is being done by the users of the web. In todays senario company has to adapt Social Media in their marketing strategies, so that company presence is felt everywhere to the potential customers or customers of the organisation.
As per statistics, Morgan Stanley report of July 2009 stated number of Social Media Users are more than email users. Also Cloud Computing2 gave the functionality of installing the Salesforce app on Blackberry or iPhone i.e. no Salesforce is adaptable to the following:
facebook, feeds, smartphone/tablet, Mobile, Location Aware, etc. Cloud 2, in conclusions and summary, is about allowing your business software to join your customers’ conversations on social media channels, providing a social channel natively inside Salesforce with Chatter, and making it all available on mobile and wireless devices.
Salesforce.com’s Cloud 2 allows your organization to bridge the divide and tap into the dialogues occurring in these new social channels. Cloud 2 is about collaboration and making the Salesforce.com platform “social” with apps like Chatter. For example: If your comapny product user is struck with unrelated problem, and instead of calling company call center or search website of the company, user searches for the relevant solution on facebook, twitter, bing etc. social media sites. This kind of situations gave birth to Cloud2 by Salesforce.com.
It means that you need to enable your knowledge base to be available to be scraped, spidered and searched by the search engines like Google so that they can be indexed, and thus found by your customers. In Nutshell you never know where your company discussion (Good or Bad) is being done by the users of the web. In todays senario company has to adapt Social Media in their marketing strategies, so that company presence is felt everywhere to the potential customers or customers of the organisation.
As per statistics, Morgan Stanley report of July 2009 stated number of Social Media Users are more than email users. Also Cloud Computing2 gave the functionality of installing the Salesforce app on Blackberry or iPhone i.e. no Salesforce is adaptable to the following:
facebook, feeds, smartphone/tablet, Mobile, Location Aware, etc. Cloud 2, in conclusions and summary, is about allowing your business software to join your customers’ conversations on social media channels, providing a social channel natively inside Salesforce with Chatter, and making it all available on mobile and wireless devices.
Security and Access Control in Salesforce
Salesforce provides quite elaborated security features, as compared to the access controls provided by database management systems or file systems.
If Salesforce data validation when applied appropriately, make data more secure and data security more transparent to the general user. Key points for access
control are:
1. Who is accessing
2. What data is being accessed
3. How data is to be accessed
Let us take each component in detail:
1. Who is accessing: Doing the access is always determined by the user who in session. Instead of specifying permissions to Users individually, we can group into 3 categories for ease:
a. Profiles
b. Role hierarchies
c. Public groups
a. Profiles: Access to business objects, such as Accounts, Contacts, and Leads can be specified. Profile specify which actions can be taken and which components will appear on the screen. Each user must be assigned a profile, and a user can have only one profile. Salesforce give you following default profiles and vary as per the Edition of Salesforce:
1. System Administrator
2. Standard Platform User
3. Standard Platform One App User
4. Standard User
5. Partner User
6. High Volume Customer Portal User and Authenticated Website User
7. Customer Portal User
8. Customer Portal Manager
9. Solution Manager
10. Marketing User
11. Contract Manager
12. Read Only
13. Chatter Only User
14. Chatter Free User
15. Chatter Moderator User
Administrators can extend these by creating custom profiles if necessary.
b. Role hierarchies: It reflect the responsibility hierarchy in an organization. For example, a sales manager should be able to see the opportunities being pursued by the sales reps that report to her, but not necessarily the opportunities of reps that report to other sales managers. Logically a role
hierarchy in Salesforce must match a company’s org chart, but it does not follow watertight compartments i.e. can be altered as per the business requirement. For e.g. if Company Secatriate requires access to all the company’s data, he can be assigned the CEO role, i.e, at the top of the hierarchy. Each user may be assigned only one role but, unlike profile assignment, role assignment is optional (though highly recommended).
c. Public groups: Used for grouping of users for the purpose of specifying access rights. Public groups can contain individual users, roles with or without subordinates, and/or other public groups. A user could be a member of any number of public groups.
2. What data is being accessed: What secures the data. In databases and file systems, this is the table or file. The equivalent in Salesforce is the
business object. We can restrict access to following in Salesforce:
a. Object
b. Field
c. Record
a. Object: At the object level, users are granted or denied access to all instances of specific types of business objects. This is the coarsest level of
data access, and it is specified for profiles, rather than roles or public groups. For example, only users in the Marketing User profile have full access
to Campaign objects.
b. Field: Field-level access provides a finer level of control. Objects consist of fields, and field-level access can be used to restrict access to individual fields. For example, Salesforce restricts access to the Created By and Last Modified By fields in all objects, preventing users from arbitrarily setting these values. Field-level access, like object-level access, is granted or restricted for individual profiles.
c. Record: It controls access to instances of objects. Rows are the individual records for which Salesforce provide the access control. For eg: A user may
have access to Opportunity objects, for example, according to object-level permissions associated with her profile, but there may be record-level
permissions that restrict which Opportunity records she can access.
3. How data is to be accessed: The “how” of data access is best thought of from two perspectives: the way users are permitted to manipulate data and the
way records created by one user are shared with other users. Users can manipulate data by CRUD operations:
a. Create
b. Retrieve
c. Update (Edit)
d. Delete
These operations are individually either enabled or disabled for each object for each profile, and they specify the way users associated with a profile
can manipulate objects and their constituent fields. Viewing and editing individual fields can be further restricted with two field-level settings,
Visible and Read-Only.
Note: field-level settings can only further restrict the access specified for the object; there is no way, for example, to make a field editable if Update
is not enabled for the object.
The way records created by one user are shared with other users is determined by:
a. Organisation Wide Defaults/ Sharing mode
b. Role hierarchy
c. Sharing rules
d. Manual sharing
a. Organisation Wide Defaults/ Sharing mode: The sharing model is set for each object by the administrator, and it determines the organization-wide
defaults for object sharing:
1. Private (only viewable/editable by the owner and users above the owner in the role hierarchy)
2. Public Read Only (Only owner, and users above the role in the hierarchy, can edit those records)
3. Public Read/Write
OWD is used to restrict the access to data, in comparison with other modes which are used to open the access.
b. Role hierarchy: The role hierarchy enables data sharing upward in the organization. By default, a users can access all the data owned by and shared
with users directly below them in the role hierarchy. This sharing can be disabled for individual custom objects.
c. Sharing rules: Sharing rules are set by the administrator, and they determine object access based on who owns the object and who accesses the object.
The settings for sharing rules are similar to those for the sharing model:
1. Read Only
2. Read/Write
d. Manual Sharing: similar to sharing rules, except it is done by users on their own data, and it must be specified on each individual
record rather than at the object level.
To conclude to meet the practical demands of securing and sharing data throughout an organization, both within and across reporting lines, flexibility is required. And flexibility leads to complexity. it is the object-level settings that determine how a record can be manipulated.
The sharing settings simply affect access. For example, if a user’s profile grants him update permission on an object, he will not be able to edit records
of that type owned by other users unless read/write record-sharing has been granted. Conversely, if read/write sharing has been granted, a user whose
profile does not specify update permission will not be able to edit records of that type.
Note: If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.
If Salesforce data validation when applied appropriately, make data more secure and data security more transparent to the general user. Key points for access
control are:
1. Who is accessing
2. What data is being accessed
3. How data is to be accessed
Let us take each component in detail:
1. Who is accessing: Doing the access is always determined by the user who in session. Instead of specifying permissions to Users individually, we can group into 3 categories for ease:
a. Profiles
b. Role hierarchies
c. Public groups
a. Profiles: Access to business objects, such as Accounts, Contacts, and Leads can be specified. Profile specify which actions can be taken and which components will appear on the screen. Each user must be assigned a profile, and a user can have only one profile. Salesforce give you following default profiles and vary as per the Edition of Salesforce:
1. System Administrator
2. Standard Platform User
3. Standard Platform One App User
4. Standard User
5. Partner User
6. High Volume Customer Portal User and Authenticated Website User
7. Customer Portal User
8. Customer Portal Manager
9. Solution Manager
10. Marketing User
11. Contract Manager
12. Read Only
13. Chatter Only User
14. Chatter Free User
15. Chatter Moderator User
Administrators can extend these by creating custom profiles if necessary.
b. Role hierarchies: It reflect the responsibility hierarchy in an organization. For example, a sales manager should be able to see the opportunities being pursued by the sales reps that report to her, but not necessarily the opportunities of reps that report to other sales managers. Logically a role
hierarchy in Salesforce must match a company’s org chart, but it does not follow watertight compartments i.e. can be altered as per the business requirement. For e.g. if Company Secatriate requires access to all the company’s data, he can be assigned the CEO role, i.e, at the top of the hierarchy. Each user may be assigned only one role but, unlike profile assignment, role assignment is optional (though highly recommended).
c. Public groups: Used for grouping of users for the purpose of specifying access rights. Public groups can contain individual users, roles with or without subordinates, and/or other public groups. A user could be a member of any number of public groups.
2. What data is being accessed: What secures the data. In databases and file systems, this is the table or file. The equivalent in Salesforce is the
business object. We can restrict access to following in Salesforce:
a. Object
b. Field
c. Record
a. Object: At the object level, users are granted or denied access to all instances of specific types of business objects. This is the coarsest level of
data access, and it is specified for profiles, rather than roles or public groups. For example, only users in the Marketing User profile have full access
to Campaign objects.
b. Field: Field-level access provides a finer level of control. Objects consist of fields, and field-level access can be used to restrict access to individual fields. For example, Salesforce restricts access to the Created By and Last Modified By fields in all objects, preventing users from arbitrarily setting these values. Field-level access, like object-level access, is granted or restricted for individual profiles.
c. Record: It controls access to instances of objects. Rows are the individual records for which Salesforce provide the access control. For eg: A user may
have access to Opportunity objects, for example, according to object-level permissions associated with her profile, but there may be record-level
permissions that restrict which Opportunity records she can access.
3. How data is to be accessed: The “how” of data access is best thought of from two perspectives: the way users are permitted to manipulate data and the
way records created by one user are shared with other users. Users can manipulate data by CRUD operations:
a. Create
b. Retrieve
c. Update (Edit)
d. Delete
These operations are individually either enabled or disabled for each object for each profile, and they specify the way users associated with a profile
can manipulate objects and their constituent fields. Viewing and editing individual fields can be further restricted with two field-level settings,
Visible and Read-Only.
Note: field-level settings can only further restrict the access specified for the object; there is no way, for example, to make a field editable if Update
is not enabled for the object.
The way records created by one user are shared with other users is determined by:
a. Organisation Wide Defaults/ Sharing mode
b. Role hierarchy
c. Sharing rules
d. Manual sharing
a. Organisation Wide Defaults/ Sharing mode: The sharing model is set for each object by the administrator, and it determines the organization-wide
defaults for object sharing:
1. Private (only viewable/editable by the owner and users above the owner in the role hierarchy)
2. Public Read Only (Only owner, and users above the role in the hierarchy, can edit those records)
3. Public Read/Write
OWD is used to restrict the access to data, in comparison with other modes which are used to open the access.
b. Role hierarchy: The role hierarchy enables data sharing upward in the organization. By default, a users can access all the data owned by and shared
with users directly below them in the role hierarchy. This sharing can be disabled for individual custom objects.
c. Sharing rules: Sharing rules are set by the administrator, and they determine object access based on who owns the object and who accesses the object.
The settings for sharing rules are similar to those for the sharing model:
1. Read Only
2. Read/Write
d. Manual Sharing: similar to sharing rules, except it is done by users on their own data, and it must be specified on each individual
record rather than at the object level.
To conclude to meet the practical demands of securing and sharing data throughout an organization, both within and across reporting lines, flexibility is required. And flexibility leads to complexity. it is the object-level settings that determine how a record can be manipulated.
The sharing settings simply affect access. For example, if a user’s profile grants him update permission on an object, he will not be able to edit records
of that type owned by other users unless read/write record-sharing has been granted. Conversely, if read/write sharing has been granted, a user whose
profile does not specify update permission will not be able to edit records of that type.
Note: If object-level permissions conflict with record-level permissions, Salesforce applies the most restrictive settings.
Subscribe to:
Posts (Atom)