Big data business scenarion Flashcards
Determining the appropriate use of standard and custom objects
The company would like to use Salesforce to store information about individuals and businesses that buy products. The current database has more than 20 million customers, and this number is expected to increase to 30 million over the next three years. Out of 20 million, almost 15 million are individual customers.Salesforce will also be used to manage products, employees, and performance reviews. In addition, stores and distributors owned by the company will need to be stored in Salesforce. Products purchased by each customer must be related to the customer’s record in Salesforce such that the owner of each customer record and the related products is the same. Each customer record will be owned by a sales agent. Similarly, employees should be related to performance reviews; when an employee leaves the company, their performance reviews must be deleted.
The Account object can be used to store information about both individual and business customers. Person Accounts can be enabled for individuals who purchase products. A separate **page layout **can be defined for individual customers.Using Person Accounts is recommended by Salesforce to make it more efficient to manage a large number of individual customers. Each person account consists of one account and one contact. It contains all standard account and contact fields. Person Accounts consume twice as much storage, as both an Account record and a Contact record is created.The purchase of extra data storage may be required, given the large number of customer records, Data storage calculations also include the Salesforce edition and number of licensed users.
**Custom objects **can be used to store information about stores, distributors, products, employees, and performance reviews. A custom object named ‘Purchased Item’ can be created for products. Master-detail relationships can be defined between Account and Purchased Item as well as Employee and Performance Review. A master-detail relationship ensures that parent and child records have the same owner and child records are automatically deleted when a parent record is deleted. Although the standard Product object could be used to store information about products, a master-detail relationship field cannot be defined on the Product object to the Account object as both are standard objects, with relationship limitations. In order to avoid confusion, a custom object that uses a different name such as ‘Purchased Item’ can be utilized instead.
Determining the appropriate use of standard and custom objects
The internal database of the company currently stores more than one hundred thousand events, which have been organized within the company and outside over the last two years. An event generally involves several employees, partner organizations, customers, and prospects, and is not related to any specific individual or record. It is typically held at one of the company’s offices in a particular country or at some private venue. The company has 57 offices in different countries, and there are 753 private venues where events are held every week. A country typically has 10-15 private venues. In the internal database, each event is owned by a particular employee of the company who is responsible for organizing the event. However, any employee can view details about the event and its venue.
A large-scale expansion is being planned, due to which the frequency of events is likely to increase by five times during the next fiscal period. However, the number of venues is not likely to change. Events and venues need to be stored in Salesforce while making sure that they follow the security model that has been implemented in the internal database. The architect must recommend an appropriate storage solution for this requirement.Determining the appropriate use of standard and custom objects
A custom object can be created to store events organized by the company. Since each record allocates 2 KB, and there are 100,000 events that need to be stored, they will require almost 200 MB of storage. The company will use the Enterprise edition of Salesforce, which comes with 10 GB storage, so there will be sufficient space to store events. The organization-wide default sharing setting of the custom object can be set to** ‘Public Read Only’** to ensure that employees can view an event regardless of its ownership.Other storage requirements should also be considered. Two custom picklist fields can be created on the Event object to allow users to specify an office and a private venue on each event. In addition, a custom picklist field can be defined to specify the country, which can be the controlling field. The picklist field used for the private venue can be the dependent field. The values in the dependent field would depend on the value selected in the controlling field. A custom picklist field can have up to 1000 values, so it can be used to store 753 private venues. However, the field would only display the venues that correspond to the selected country.
Determining the appropriate use of standard and custom objects
Individual customers typically place orders on the company’s website. Businesses typically call the sales department to place orders. Information about sales orders must be stored in Salesforce. Each sales order should be visible only to the sales representative who is assigned to the sales order and users above them in the role hierarchy. A sales user must be able to specify the status of a sales order. The status of a sales order can be one of the following twelve values:
1.Pending
2.Awaiting Payment
3.Awaiting Fulfillment
4.Awaiting Shipment
5.Awaiting Store Pickup
6.Partially Shipped
7.Completed
8.Shipped
9.Canceled
10.Declined
11.Refunded
12.Business Verification Required
The architect should suggest an appropriate solution that can be used to store and track this information.
A custom object can be created to store sales orders. Since the company uses its own business process for managing sales orders that does not include ‘draft’ and ‘activated’ orders, it is better to use a custom object instead of the standard Order object. A custom picklist field can be created on the object to allow users to specify the status of a sales order. Also, in order to ensure that a sales order can only be viewed by the sales representative who owns it and any user above them in the role hierarchy, the organization-wide default sharing setting of the custom object should be set to ‘Private’ and the ‘Grant Access Using Hierarchies’ option should be selected.
Determining an appropriate solution for accessing large data volumes
The sales department of the company issues an invoice when a sales order is finalized. There are more than 50 million invoices that are stored in an external system. The number of invoices is likely to increase by 5% each month. Each invoice related to a sales order should be visible in Salesforce on the page that displays the sales order. If an invoice in the internal database can be viewed by a user, then they should also be able to view the invoice in Salesforce. The internal database does not store record IDs of sales orders in Salesforce. The architect needs to recommend an appropriate solution, considering both data storage space and performance.
Due to a large number of invoices in the external system, invoices should not be stored in Salesforce because it could have a negative impact on performance. Salesforce Connect should be used for this use case. An external object can be used to make invoices visible in Salesforce. When setting up Salesforce Connect, the ‘Per User’ Identity Type should be selected for authentication to ensure that users can only view the invoice data that they can access in the external system. Once they have been granted access to the external data source, they can set up their own authentication settings for the external system. An indirect lookup relationship can be defined on the external object to the ‘Sales Order’ object to link invoices to sales orders in Salesforce. Since the external system does not store Salesforce record IDs, a custom unique, external ID field on the ‘Sales Orders’ object can be used to match against the external object’s indirect lookup relationship field. The ‘Invoices’ related list can be added to the page layout used for sales orders to make related invoices visible on sales orders.
Determining an appropriate solution for performance and scalability
The company is considering an AppExchange application for managing human and non-human resources, such as employees and inventory, respectively. There are 50,000 employees who work for the company throughout the world. With the exception of board members, each employee receives a performance review every week. There are more than 5 million performance reviews that have been conducted so far. The current inventory consists of 50 million items, but this number is likely to increase by 10 million every year as part of the company’s expansion plan. An item can be one of the 200 different types of products that are sold by the company. Employees and performance reviews will be owned by specific employees who work in the HR department. Items will be owned by a small number of individuals who work in the sales department.
The architect needs to recommend a performant and scalable solution for storing the records in Salesforce while ensuring that the intended ownership and security model does not have any negative impact.
An appropriate data archiving strategy can be utilized to ensure performance and scalability. As the number of performance reviews and items stored in the system increases, the total volume of data will increase, and performance will degrade as time goes by. Archiving data at the same rate at which it comes into the system can prevent this negative impact on performance.The company should either look for an AppExchange product that provides a suitable data archiving strategy or consider an on-premise solution for archiving data on a regular basis. As new records are created, old records can be archived daily, weekly or monthly.
It would also be important to ensure that a single user does not own more than 10,000 employee, performance review or item records. When a single user owns more than 10,000 records of an object, that condition is called ‘ownership data skew’, which can increase the probability of performance problems, such as long-running updates. The ownership of the records should be distributed across a greater number of users. If the records need to be owned by a small number of users, then they should not be placed in the role hierarchy or only be placed in a separate role at the top of the role hierarchy.
Big Object Scenario 1
Cosmic Computer Parts is a large computer parts distributor with a wide range of customers from individuals to large commercial businesses. The company has been using Salesforce to manage customer orders for 4 years. The number of orders is increasing by about 5% each year. In the previous fiscal year, 4,000 orders were received, and each order contained an average of 20 parts as order products.The management is concerned about slow report performance when order products are included in reports. The data architect has been asked to advise what can be done to improve their performance without paying extra for additional storage. Order products must be retained for a minimum of 10 years. However, once the reports for the previous fiscal year have been completed, the records created within the year will not be required by the users.
A big object can be used to meet this requirement. Currently, without any additional licensing cost, a big object can contain up to 1 million records. With the 5% annual increase in the number of orders, it is unlikely that the total number of related order products will exceed this limit in the near future. Order products can be inserted using Data Loader into the big object annually after the end of the fiscal year, and the records can then be deleted from the original Order Product sObject. This will improve the reporting performance as only the order products created during the current fiscal year will be stored in the sObject. However, it is important to consider that, when the company does the reach the limit, it will be necessary to purchase additional storage capacity for the big object.
- big object for orders older than a year
- Data loaded load archived orders into big object yearly
- then archived records can be deleted from Product Order object
Big Object Scenario 2
Cosmic Maternity Wear is a long-established online business that specializes exclusively in maternity wear for the Australian market. It has been using Salesforce for customer relationship management for over 10 years. The number of contact records in its Salesforce org has increased to over one million. A contact record contains information about the customer, including delivery address, date of birth, last order date, and the number of children (which is a calculated roll up summary field). The company has decided that, if the contact’s last order was 5 or more years ago, the contact should be marked as inactive and archived. Access to any contact that is marked as inactive will be required rarely. The data architect needs to recommend a suitable solution for this use case. Some of the contact fields, such as date of birth, are considered more sensitive, so any solution must take this into consideration.
It is possible to use a big object for this requirement. A big object is able to handle the very large data volume of archived contacts. These records can remain stored and accessed within Salesforce. Extra licensing cost is only required if more than 1 million records need to be stored. There are, however, some considerations related to the use of a big object. Big objects support limited field types, so it is possible that some field conversion may be required to prepare the contact records. For example, custom picklist, multi select picklist, formula and roll up summary fields are not available, so the data in such fields would need to be converted prior to insertion.
Also, encrypted fields are not supported. Any archived encrypted fields from the Contact object would be visible as clear text, so this also needs to be considered. The visibility of date of birth and other sensitive fields can be controlled via Field Level Security, which is available for big objects. Since big objects do not support ‘Date’ fields, a custom field of type ‘Date/Time’ can be used to store the date of birth. A default value of ‘00:00:00’ can be used for the time to ensure consistency.
- big object for archived records
- extra cost of has > 1 million records
- rollup field has to be converted
- encrypted fields are not supported and will appear in plain text
- Field level security for sensitive data is available on big objects
- Date field has to be converted to DateTime field
Cosmic Aesthetics is using a big object to store archived contact records. Records include details of buyers who ordered products for themselves, including date of birth and the number of children. A contact is archived if the last order date was more than 4 years ago. The company’s Salesforce administrator has been annually inserting newly archived contacts into the big object. There are now more than 10 million such records in the big object. The company now wishes to launch a new marketing campaign to promote a new range of ethically manufactured cosmetics which it believes will appeal to some of the former customers. The sales director wishes to query the archived contacts and filter them to create a list of contacts for the campaign. The campaign will target only those contacts who live in specific postal codes and are within a certain age range. Their number of children should also be within a specific range. Moreover, they should have placed their last order less than a certain number of years ago.
Big object records can be queried using Bulk API or Batch Apex. Bulk API can be used by external applications to query the records in Salesforce, and Batch Apex can be used by internal applications that are native on the Salesforce platform. In this case, Batch Apex can be used to retrieve the archived contacts that meet the target demographic for the product campaign.Once the big object records are retrieved in the Batch Apex operation, new (standard sObject)contacts, for example, can be created based on the data, and a new sObject Contact list view can be configured to display the list of contacts targeted by the campaign. It is important to note that, like Bulk API, Batch Apex are run asynchronously, so the results are not immediate since the operation is executed in a different transaction, when org resources are available, after the request is initiated.
- BulK API - External
- Batch Apex internal
- After records retrieved with Batch Apex - new standard or custom object can be created to store this data
- List view can be created to see a list of the created objects
Cosmic Weather Services collects detailed temperature records from thousands of weather stations across North America using REST API. Each weather station records the temperature every five minutes, and transmits all daily readings back to Cosmic Weather Services once every 24 hours.The company is trying to determine if a Salesforce feature can be used to store these weather readings, given that around 1 million new records will be created every week. The data architect needs to recommend a suitable feature that could be utilized for this very large ongoing data storage requirement.
A big object could be utilized to store these weather records. Big objects can store billions of records, but extra Salesforce licensing is required if more than 1 million records need to be stored in a big object. As the information from each weather station is transmitted daily, these daily records could be inserted nightly into a big object via a scheduled batch job.
- Big object
- Extra SF licenseing > 1 mil
- nightly batch job
