SFDC Other Platform Features
0 likes30 views
This document provides an overview of various Force.com platform features including workflow and approvals, analytics, internationalization and localization, and single sign-on. It describes the key components of workflows, approval processes, reports, dashboards, and how to configure internationalization, federated single sign-on, and delegated single sign-on.
SFDC Other Platform Features
- 1. Force.com Other Platform Features Sujit Kumar Zenolocity LLC © 2012 - 2024
- 2. Overview • Workflow and Approvals • Analytics • Internationalization and Localization • Single Sign-On
- 3. Workflow Rule – 5 Parts • Object: Can apply to a single object at a time. • Evaluation Criteria: what types of actions on the object causes the rule criteria to be checked. Eg., record created or edited. • Rule Criteria: formula expression that, when true, causes your workflow actions to be triggered. • Immediate Actions: executes immediately. • Time Dependent Actions: deferred till a future time and gets executed only if the rule criteria is still true at that time in the future. Time-based workflow cannot be executed when evaluation is set to "Every time a record is created or updated".
- 4. Possible Actions for Workflows and Approvals • Create a new task. • Update a field. • Send an email notification. • Send a new outbound message. • Use an existing action. • Locking a record.
- 5. Workflow Rules • Can be active or inactive. • To create and manage workflow rules, go to the App Setup area and click Create ➝Workflow & Approvals ➝ Workflow Rules. • Run in the background. • To enable logs go to Admin Setup area & click Monitoring ➝ Debug Logs. Click the New button. Select one or more users to enable debugging and click the Save button. • As the selected users perform actions in the system, their log entries become available that contain information about workflow rules triggered, as well as database operations, validation rules, resource consumption, and Apex code errors.
- 6. Approval Processes • Special workflow template, defined on a specific object. • Define 4 states that a record can exist in - Submitted, Approved, Rejected, Recalled. • Workflow actions execute when a record transitions to a new state. • Rules are used to route the record to users relevant to each state. • Approved state has a more specific state called final when all relevant parties have approved it. • Available in Enterprise, Unlimited and Developer Editions.
- 7. Approval Process • Specifies the steps necessary for a record to be approved and who must approve it at each step. • A step can apply to all records included in the process, or just records that have certain attributes. • An approval process also specifies the actions to take when a record is approved, rejected, recalled, or first submitted for approval. • The 2 wizards for building an approval process are the Standard Setup Wizard and the Jump Start Wizard. • Can be either single or multi-select process.
- 8. Approval Process Configuration • Active: Like workflow rules, approval processes must be in an active state before records can be submitted to them. • Entry Criteria: The entry criteria define what records can be submitted to this approval process. When a user attempts to submit a record that does not meet the entry criteria, an error message is displayed. • Initial Submitters: This field indicates who is allowed to submit a record for approval. Submitters can be dynamic based on the record itself; for example, the creator or owner. They can also be static lists of groups, roles, and users.
- 9. Parallel Approval Process • Allows specifying (up to 25) multiple approvers simultaneously. • Two options to approve: • Approve or reject based on the first response. • Require unanimous approval from all selected approvers. The approval request is rejected if any of the approvers reject the request.
- 10. Retrieve Approval Process Information • ProcessInstances: information about approval processes active on records. • ProcessSteps: audit trail of approval activities on records. SELECT Week_Ending__c, Total_Hours__c, (SELECT Status FROM ProcessInstances), (SELECT IsPending, StepStatus FROM ProcessSteps) FROM Timecard__c
- 11. Multi-Step Approval Process • Each step can approve, reject or skip to the next step depending on filter criteria or formula. • Perform all rejection actions (rejection action for this step and final rejection actions) or perform the rejection actions only for a particular step. • When the final step approves, all final approval actions are performed.
- 12. Dynamic Approvals • Used to route approval requests to users based on values in lookup fields of the record requiring approval. • Approver names are defined dynamically in the record that needs to be routed for approval. • Use Apex code to dynamically route approval requests to different users within your org.
- 13. Approval Processes using Apex Code • Records can be submitted for approval processing and accept, reject, and recall records from Apex code and the Web Services API. • Example of submitting a record from Apex: Approval.ProcessSubmitRequest req = new Approval.ProcessSubmitRequest(); req.setObjectId('a048000000BO4W3'); Approval.ProcessResult result = Approval.process(req); System.debug(result.success);
- 14. Analytics • Determine early in the development process which reports are needed so that the right object model can be designed to support both the transactional and the analytical requirements of the application. • Reports – detail or aggregate-level views • Dashboards - Pages consisting of components that consume data from reports and display it graphically in a uniformly small visual footprint. Provide a window into various types of data across a business. • Snapshots - copy the output of a source report into a custom object on a fixed time schedule. Show trends.
- 15. Reports • Creation – created against a primary object and a set of related objects, drag-and-drop UI, query and aggregate data, results in tabular, summary or matrix form. • Running Reports – view in UI or scheduled and emailed. • Reports data is always generated in real time. When a report is saved, reports configuration parameters are stored - but the generated data is not stored. • Custom Report Types – complex reports difficult to create from the UI.
- 16. 3 Types of Reports • Tabular – displays rows of data in a table format. Cannot be used for dashboards. • Summary – Allows grouping of rows of data. • Matrix – Most complex, allows records to be grouped by both columns and rows. • Both summary and matrix reports can be used in a dashboard.
- 17. Report Builder • Report Format – tabular (detail data), summary (aggregate & detail data), matrix (aggregate data). • Drag-and-drop fields • Summarize Fields – sum, avg, min, max. • Group Fields – up to 3 fields, valid for summary and matrix formats only. • Order Columns • Add Filters to data • Display report data as Charts for summary & matrix formats. • Conditional highlighting of data.
- 18. Custom Report Types • Simplify object models by flattening relationships between a primary object and up to 2 related child objects. • Object relationships that are supported by Custom Report Types are - 1. Include all records that have children (inner join). 2. Include all records that may or may not have children (left outer join).
- 19. Custom Report Type • Let the developers define which all fields should be available in a report. • Allow user to change field names. • Allow developers to select related fields (up to four levels). • Allow developers to add sections to group fields. • Once a custom report is created it is available in reports tab and user may create reports from it.
- 20. Dashboards • Are graphical representation of reports. • Can be generated for summary or matrix reports (and not for tabular reports). • Display data as per last time report was run. • A dashboard can have up to 20 components. • Support automatic refresh and email. The refresh and email can also be scheduled at intervals - daily, weekly, monthly.
- 21. 4 Types of Dashboards • Chart - used for comparisons. • Table - good for showing top five or bottom five lists. • Gauge - used to show progress towards a goal. • Metric - shows a single number. • Visualforce page - used to pull data from other sources.
- 22. 6 Types of Charts • Vertical column • Horizontal bar • Line • Donut – show proportion of single value against total and also show the total value. • Funnel - proportion of values against each other. • Pie - demonstrate proportion of single value against total.
- 23. Access to Reports & Dashboards • Reports and Dashboards are stored in folders. • Folders – determine who can access the reports and dashboards. • Running User – determines what data is displayed by the report or dashboard. • Running User can be a specific user (static dashboard) or the logged-in user (dynamic dashboard). • Reports present in public folders can be emailed to Salesforce users. • Reports display up to 2000 rows of data. Larger reports can be emailed to Excel.
- 24. Internationalization • Multilingual – can be translated into 16 languages in 2 ways: Translation Workbench (not enabled by default) and Custom Labels (externalize strings). • Multiple Currencies – default is single global currency per organization. Supports multiple currencies at the record level. • Advanced Currency Management (ACM) – optional feature that needs to be enabled. Supports currency exchange rates that vary with time.
- 25. ACM • With ACM disabled, currency conversion rates are not sensitive to time. • Can be used only for standard fields on the Opportunity object. • To use dated currency rates on custom objects, run SOQL on the DatedConversionRate standard object
- 26. Single Sign-On • Federated Single Sign-On: a digitally signed assertion message is posted from a Web page into Force.com’s login servers. If the assertion is valid, the user is logged in to Force.com. • Delegated Single Sign-On: Delegated SSO uses a custom Web service you implement to decide whether a user should be permitted access to Force.com allowing you to integrate Force.com with any back-end identity provider.
- 27. Federated Single Sign-On • Assertions are messages encoded in XML, digitally signed, and posted to Force.com from the Web browser. These messages, when verified, instruct Force.com to create an authenticated session for a user on behalf of your corporate systems. • Force.com supports Security Assertion Markup Language (SAML) 1.1 and 2.0. • A sys admin configures Force.com to receive SAML assertions by specifying a digital certificate to verify the signed messages and the location and format of the user’s identity in the assertions. • Not supported for the web services API.
- 28. Configure Federate Single Sign-On • Issuer: The issuer value must map to the issuer element in the SAML assertion. • SAML User ID Type: This value specifies how Force.com is to interpret the user value provided in the assertion. It is either a Force.com username or a federation identifier, which is an optional field on the user object. • SAML User ID Location: This setting instructs Force.com on where to find the user in the assertion. It is in either a Name Identifier element or an Attribute element. • Salesforce Login URL: This is a value generated by Force.com. Post your SAML assertions to this URL. • Identity Provider Certificate: Your system, the one generating the assertion, is the identity provider. The assertion must be digitally signed. This certificate is the public half of the credential’s key pair, used by Force.com to verify that your system indeed signed the assertion. This field displays information about the certificate you’ve uploaded.
- 29. Testing Federated Single Sign-On • After federated SSO is configured, generate SAML assertions and test them using the SAML Assertion Validator. • On the Single Sign-On Settings page, click the SAML Assertion Validator button. Paste a plain XML or Base64-encoded assertion into the text area labeled SAML Response and click the Validate button. • When the assertion is validated with no errors, you know it can be used to actually log a user in to Force.com when Base64-encoded and posted to the Salesforce Login URL.
- 30. Delegated Single Sign-On • Force.com provides the username, password, and source IP address of the user attempting to log in. An authenticating web service returns true or false, indicating whether the user should be allowed to enter Force.com. • By default, delegated SSO is not enabled in your Force.com organization. To enable it, contact Salesforce support by logging a case.