Salesforce Deployment with Ant

This first video post provides a brief introduction to scripted Salesforce deployment with the Force.com Migration Tool and Ant.

Salesforce Standard Reporting (2 of 3) – Report Builder

This post is the second in the Salesforce Standard Reporting series and serves to outline the capabilities and constraints of the standard Report Builder. I’m using the term Report Builder loosely here as a term that groups the majority of the on-platform standard reporting capabilities.

The key message of this series is simple; a solid understanding of how the Salesforce standard reporting tools work in practice, and the reporting patterns supported, can avoid the necessity to employ additional, expensive off-platform reporting tools. The earlier this thinking is applied, the greater the likelihood of success.

Report Builder Capabilities
The following sections outline the key capabilities of the Report Builder with a view to establishing the context within which the supported reporting patterns can be described.

  • Fields
  • The right-hand-side of the Report Builder UI displays the sections and fields defined within the selected Report Type. All reports are based on one principal Report Type, whether Standard or Custom.

    Note, at a conceptual level it can be useful to mentally picture the data presented by the report type as single-big-table of denormalised data (just rows and columns like a spreadsheet) with the maximum number of rows equating to the number of child records at the lowest level.

  • Report Formats
  • Report Builder supports 4 formats;

    1. Tabular
    A simple view comprised of an ordered set of columns as-per a spreadsheet, with no summarisation of data, the lowest level input records are presented.

    2. Summary
    Extends the tabular view to enable specified field values to be used to group input records with subtotals per grouping.

    3. Matrix
    Extends the summary view to enable both row and column groupings, as per Pivot tables in the Excel context.

    4. Joined
    Enable multiple sub-reports (blocks) to be added to a single report, with each block being linked to a specific report type and configured with its own fields, filters and sorting.

    4. Joined Report

    With a joined report input records can be grouped across the blocks using fields from common parent objects; such fields are listed under Common Fields. The common parent object must be applicable across all report types added.

    5. Joined Report Run

  • Filters
  • Each report type added to a report has a Dynamic Filter (e.g. “My Accounts”, “My Team’s Accounts”), a date field filter (which requires a date field to be specified, plus a range), and custom filters where any field in the report type can be filtered against static value or relative date value criteria. If a historical trending report type is used then a Historical Date filter is added which allows selection of up to 5 snapshot dates.

  • Bucket Fields
  • Bucket fields can be defined which map a list of input field values against a bucket field output value. The bucket field can then be added as a column, to provide a summarised view of the input data. Bucketing can be useful for use cases such as grouping strategic accounts or extensive ranges of data into smaller distinct set of High, Medium, Low range values. Note bucket fields aren’t available for Joined Reports.

  • Formulas
  • Report Builder supports Custom Summary Formulas and Cross Block Custom Summary Formulas. In the former case, the min/max/sum/average value of numeric fields can be used as inputs to a formula expression, the output of which displays at the selected summary level. Each report can have 5 such formulas. Cross Block Formulas extend the same approach, but enable block specific inputs from multiple blocks to be assembled into a single expression.

  • Report Generation
  • Once defined a report can be run to generate the output. In view mode Report Builder supports filter manipulation, data export, a printable view (html) and the ability to schedule future runs with email distribution to named users or public groups.

  • Report Charts
  • Report Builder enables summarised report data to be presented on a chart located directly within the report. Summary groups can be added to the chart as rows or columns (depending on the type of report vertical/horizontal bar etc.), with a selected aggregated value available on the opposing axis. Up to 2 levels of grouping can be selected per chart, with combination charts enabling additional aggregated values to be plotted; this potential ranges from 1 to 3 values depending on the type of chart. Cumulative Line Charts enable the aggregate values to be plotted as a cumulative figure.

    Report Builder has other capabilities not mentioned in the outline above; multiple currency handling, conditional highlighting and the ability to invoke a parameterised report via URL are notable examples. However for the purpose of setting context, the above provides a sufficient coverage.

Report Builder – Benefits
The Report Builder tool is a classic transactional reporting tool, with a deliberate focus on usability over complexity. In my view this is definitely the right approach; report production should be an end-user concern whenever possible. A technically-oriented, complex report builder would clearly detract from that possibility. Self-sufficient end-users, confident that they can report and track accurately can be the best adoption advocates possible. This best-case scenario has the added benefit of removing any potential resource bottleneck associated with the implementation project/IT team delivering all the reporting outputs. The usability of the report builder correlates to its functional simplicity, which in turn imposes constraints on the type of reporting possible. It is the case however that the Report Builder does provide a good level of coverage for the majority of transactional reporting patterns, some examples are listed below.

  • Transactional Reports
  • Basic tabular reports are easy to produce; the WYSIWYG drag-and-drop editor provides a rich, intuitive design environment for basic transactional reports.

  • Summary Reports
  • Basic summary reports that can be satisfied within the grouping limits are straightforward to produce. For summary reports, 3 levels of grouping can be applied, for matrix reports it is possible to have 2 column groupings and 2 row groupings, so 4 in total. Excel allows an unlimited number of row or column fields in a PivotTable report (limited by system memory); in this light 4 appears restrictive.

  • Exception Reports
  • An often overlooked capability of Report Builder is the Cross Filter (the Row Limit filter is another example). Cross Filters allow explicit control over the join type (with = inner, without = outer) and enable the production of exception reports such as “Accounts without Cases”. Within a Cross Filter, up to 5 sub-filters can be added that increase the selectivity applied to the related object. This type of filter is typically used in conjunction with rollup summary fields to cover scenarios such as “Closed Opportunities over time, without a particular product”.

  • Embedded Analytics
  • Embedded data visualisations within report outputs, or page layouts provide a convenient method for combining the headline statistics and underlying detail in a single view. In the former case, if you then consider the native ability to schedule the generation and distribution of reports, the potential business utility is considerable.

  • Dashboards
  • Report Builder produced reports underpin standard dashboard components, enabling a single report to deliver both the transactional view and data visualisations drawn from the same data. The dashboard features are extensive but key features beyond the obvious are Dashboard filters and Dynamic dashboards. In regard to the former, up to 3 filters can be applied to drill into the data, each filter may have up to 10 (50 hard limit) filter options. With the latter it’s possible to define a single dashboard that inherits the record visibility of the viewing user. This relatively new capability removes the historic requirement to maintain duplicate dashboards set to run with different specified users. Dashboard filters can be applied to Dynamic dashboards providing a high degree of flexibility and through consolidation a significant reduction in the number of dashboards required.

  • Scheduling and Distribution
  • Scheduling reports (and dashboards) with automated distribution to Salesforce users is easy to do and a very effective communication tool.

  • Report Notifications
  • Report Notifications is a recent feature addition and a very interesting one. In short, users subscribe to reports by providing a time or recurrence pattern to run the report, user-defined conditions to evaluate against the generated report data and selected actions (email, post, Salesforce1 Notification, Apex code) to invoke if the condition logic evaluates to true. This powerful capability enables reports, typically passive in nature, to be proactive drivers of action. The notification model also avoids the common issue that scheduled reports, regardless of content, tend to lose their effectiveness over time.

  • Report Snapshots
  • Report Snapshots enable a tabular or summary report output to be mapped to fields on a custom object; scheduled generation of the report populates the custom object with the report data. This feature is limited to the population of up to 2,000 records in the target object per execution.

A final benefit associated with Report Builder is the wealth of packaged reports provided as standard and also available on the AppExchange. It always makes sense to utilise the available reports as far as possible and build any exceptions. It’s surprising how many implementations ignore the packaged reports and expend time (and money) re-creating similar outputs.

Report Builder – Limitations
As introduced in the preceding section, Report Builder is implemented to deliver a robust, simple set of reporting functions focused on end-user usability over complexity. The following set of limitations highlight some of the reporting patterns not directly supported by the Report Builder.

  • Object Relationships
  • Report Builder consumes report types in the construction of reports, each report type is limited to 4 object relationships meaning parent to child relationships, a further 56 objects can be referenced by lookup. Note, if a single report contains columns from more than 20 objects an error is thrown. The parent to child relationship limit is key to understand when deciding upon the primary object for a custom report type.

  • Comparative Analysis
  • Report types do not support the addition of sibling objects, the parent to child object relationships are strictly linear. One common case where this constraint can manifest is the production of comparative analysis style reports which contrast records in one object against another. For example, consider a scenario where date-based, budget values and actual values are held in separate objects, both linked to a parent cost centre object. With a joined report it’s possible to bring the data together and group by cost centre – but there’s no direct means to group the data by date to deliver a side-by-side analysis of actual versus budget per date period. There are techniques to mitigate this issue, the next post in the series will cover such concepts.

  • Date Ranges
  • Where input records represent a date range between two boundary date fields (Start Date and End Date for example), the Report Builder requires that one of the date fields is used in date-based grouping. Individual dates within the range can’t be referenced. Reporting tools often provide a pivot function with dynamic columns that enables ranges to be exploded within the reporting layer, avoiding the data storage overhead of storing the transactional data at the lowest level.

  • What-if Analysis
  • Report Builder does not enable the input data to be adjusted, thereby precluding scenario-based, what-if analysis type reports. There is of course the option to export the data to Excel, which does cater for this requirement.

  • Formulas
  • Report Builder supports sub-total, grand total and cross-group summary formula fields, but not row-level formula fields. For such requirements, a custom field can be added to the object, but the means to isolate the formula field to a report would help maintain a lean configuration.

  • Sub Reports
  • Joined reports, dashboards, embedded analytics and report charts provide effective, but simple, capabilities for the delivery of composite report views. Many reporting tools support the concept of sub-reports, or nested data, where multiple transaction level views, with or without common relationships, can be combined.

  • Report Distribution
  • A common complaint raised in relation to the standard reporting tools is the inability to schedule a report for distribution to individuals who are not Salesforce users.

  • Historical Trend Reporting
  • The Historical Trending Custom Report Types expose data for the last 3 months only, and Reporting Snapshots are limited to 2,000 (summarised) records per execution. One or both of these capabilities will provide an effective historical data analysis solution for many customers, at larger data volumes and for larger organisations the limits may be intractable.

The next and final post in the “Salesforce Standard Reporting” series outlines the key data model techniques that can help maximise the potential of the standard reporting tools.

Salesforce Standard Reporting (1 of 3) – Report Types

A key contributor to the successful implementation of Salesforce is an informed approach to reporting. I’ve said this many times and have been meaning to complete this short set of posts for a long time. The basic idea is that the delivery of key reports and analytics on-platform using the standard reporting tools should be a primary objective for all implementation projects. This approach may not always be feasible where requirements are complex or atypical, however the standard reporting features should be exhausted before an off-platform business intelligence tool or analytics cloud is employed. Such complementary services come at a significant price point.

In order to maximise the potential of the standard reporting features, both expertise and experience must be applied early in the project. Early consideration of reporting requirements enables a data model design that supports the production of required reports via the standard tools; this should never be an afterthought but often is.

This short series of three posts serves to outline the key concepts, the reporting patterns supported by the standard tools and critically the implications on the data model to be considered. This latter point is imperative as an effective Salesforce physical data model strongly reflects the reporting of data; a key differentiator from a pure physical data model applied to a traditional RDBMS.

The first post in the 3 part series focuses on the foundational concept of Report Types.

Report Types
In the context of outlining the capabilities of the standard reporting tools, the following concepts are significant.

  • Standard Report Types
  • Report types abstract the data model into logical reporting entities on top of which reports are built. This model can’t be circumvented.

    1. Select Report Type

    Standard Report Types are automatically created for all Standard Objects and for Custom Objects when the “Enable Reports” or “Allow Reports” checkbox is checked. Standard report types can’t be edited, new fields are automatically added.

    For unrelated objects, or parent objects in lookup relationships only, a single Standard Report Type is created, named as per the object plural name. E.g. “Rubric Scores”. Note there are exceptions to this where enabled standard features (e.g. Salesforce to Salesforce) add object relationships which result in additional report types (e.g. “Rubric Entries with Connections”).

    For parent objects in master-detail relationships multiple Standard Report Types can be created; one per master-detail relationship. E.g. “Rubric Entries with Questions”. Additional report types are added for each lookup relationship on the child object (e.g.”Rubric Entries with Questions and Score”, “Rubric Entries with Questions and Criterion”), where Score and Criterion are parent object relationships of the lookup type. Additional report types are also added for each additional master detail relationship (e.g. “Accounts with Assessments and Courses”).

    Standard report types are not created for grand-child relationships, or for child objects in master detail relationships.

    Note, the applied naming convention uses the child field label for lookup relationships and the parent object plural label for master detail relationships.

    A key feature of Standard Report Types is the ability to navigate up a lookup relationship from Child to Parent. The example above “Rubric Entries with Questions and Criterion”, is logically a parent to child (master-detail), then child to parent (lookup) traversal.

  • Custom Report Types
  • Custom report types (CRT) enable the definition of a report type that includes up to 4 levels of parent-to-child relationship, regardless of whether each relationship is lookup or master-detail type.

    2. CRT Definition

    Each CRT has a layout which can be configured with custom sections and selective field inclusion across the objects. Objects and Fields can also have CRT specific labels added and a flag set to include selective fields in new reports by default.

    Note, an often overlooked feature of Custom Report Types is the ability to add a parent object field regardless of whether the relationship is master-detail or lookup (although the UI indicates lookup only, both work). This de-normalisation technique is incredibly powerful; up to 5 levels of the parent object hierarchy can be traversed.

    3. CRT Add Lookup Field

    CRTs therefore enable the production of specialised, convenient report types providing a focused set of denormalised fields for a specific purpose. Many successful Salesforce implementations adopt a model where Salesforce Administrators or Developers produce the required CRTs, and the end users build the reports.

  • Historical Trending Custom Report Types
  • Historical Trending is a reporting feature, added in the Winter ’14 release, which can be enabled and configured on a per-object basis. For each enabled object a special CRT is added (e.g. “Rubric Entries with Historical Trending”), containing up to 8 selected fields (numeric, date, picklist, currency). Up to 3 months of data is available via the CRT.

    The next post in the “Salesforce Standard Reporting” series will cover the capabilities of Report Builder to consume the date exposed by report types.

Salesforce Summer 15 Platform Highlights

Once again a new release is almost upon us – this time it’s Summer ’15 with its suitably summery ice cream van logo. The rollout starts on May 8th for sandbox instances, followed by NA production instances on May 22nd. EU instances will be upgraded on June 13th. If you can’t wait until then, Summer ’15 pre-release access is available via this link.

The preview Summer ’15 Release Notes can be found here. Note, to keep up-to-date with updates to the release notes follow @salesforcedocs

This post briefly outlines selected highlights related to the Force.com platform (in no order of significance).

– features are GA if not indicated otherwise

Data Loader for Mac
At long last there is now a supported data loader for the Mac. This is great news for longtime lexiloader users. The new data loader is accessible from the setup menu – see below. Note, the CLI/batch mode is only supported on the Windows platform.

Data Loader for Mac

Lightning App Builder
Now GA the Lighting App Builder enables the point-and-click definition of custom app pages for Salesforce1. The development model is declarative application composition using standard, custom or third-party components developed using the Lighting Component Framework (Aura).

Lightning App Builder - Setup

Lightning App Builder 1

Lightning App Builder 2

Lightning App Builder 3

Lightning App Builder 4

Omni-Channel
Omni-channel is a service cloud capability that creates abstract work items from inbound support requests, regardless of channel, and provides intelligent workload management and real-time intelligent routing of work items, including routing back to agents who have previously handled work items for the same customer. This latter point being the highlighted distinction from multi-channel. This functional area looks immense and complex, but very interesting in scenarios where resource management requirements go beyond the the standard capabilities of queues/assignment rules etc.

BigObjects (Pilot)
An interesting new capability for storing large scale datasets on-platform and fully integrated with standard data via relationship fields, SOQL and API access. BigObjects are defined via the metadata API and loaded via API only. The data remains read-only. The absence of a setup UI for this new feature is indicative of an early stage pilot, as is the specific set of use cases targeted for the pilot programme (Customer360, Data Archive, Data Lake, Email Event Ingest).

The release notes make reference to a “BigObject Implementation Guide” which doesn’t appear to be available quite yet. It will be interesting to understand more about the limitations of this feature and cost, and also the impact on exiting platform limits (for example, the SOQL Query Row governor limit).

Chatter – Feed Post and Comment Editing
Editing can now be enabled for standard Salesforce users via permissions. Free, external, partner community and HVCP users are excluded from this new functionality. The edited post or comment is marked to indicate when the edit took place. Note, where @mentions are used, only newly added users are notified following the edit, not users mentiond originally.

Chatter Post Edit

Receive Debug Logs Predictably
Historically it has been difficult to comprehend the factors that influence the log level applied to debug log output. This can be a real pain point for developers especially where the debug log becomes truncated, but a seemingly restrictive setting has been applied yet ignored. Summer 15 applies a clear and predictable precedence logic to log levels, with the Developer Console trace flags first in this predictable order of precedence.

Apex:New Code Coverage Calculation for Multiline Statements
Prior to v34.0 multi-line statements were counted as 1 line, now the count accurately reflects the number of lines in the statement. The impact of this calculation change could be an increase in coverage or a decrease. The latter arising from scenarios where subsequent conditions in the multiple line statement aren’t evaluated. Expect to see a reasonable degree of variation in the coverage % in any class where multiple line statements exist.

ISV Package Streamlining
The list of components that can be deleted from a managed package in release state is extended to cover Custom Settings and Permission Sets. Anyone involved in ISV development will appreciate this increasing capability to remove obsolete components from existing packages.

Platform Encryption
Where data protection/compliance requirements must be addressed, Summer 15 provides a new data encryption layer that ensures data is high-strength (256-bit AES) encrypted at rest. This new capability applies to files (attachments etc.), standard fields and custom fields and supports multiple text-derivative field types, search and the declarative features of the platform. This differs greatly from the classic field encryption mechanism which supported a specific text field type only and could not be searched or referenced in workflow/approvals etc.. Note the new Platform Encryption capability incurs an additional cost.

Spring ’15 Chatter Features

In advance of taking the Spring ’15 certification maintenance exams I’ve been reading the release notes one more time, with a focus on the broader picture, not just the platform elements and headline features that catch the eye during the pre-release phase. I tend to follow this regimen for every release and inevitably the detail of a number of smaller features/announcements are picked up that were simply skimmed on the first review, or indeed added to a later version of the release notes – this happens (so always check you have the latest version). In regard to Spring ’15 the low-key features of interest relate to Chatter and are covered briefly below.

1. Add Records to Chatter Groups
With this feature it’s possible to relate arbitrary records to a Chatter Group via the “Add Record” publisher action on the Group Layout (this needs to be configured). The utility of this feature appears to be twofold; convenience and communication. For example, if we have a collaboration group for a sales campaign, we can now list the targeted account records on the group page and access via a convenient link. It would seem that the relationship is one-way, it doesn’t appear possible to view the groups to which a record is related from the record detail page. Note, feed posts at the record level are not shared with the group.

Group Records 1

Group Records 2

2. Question-to-Case (GA)
Chatter Questions is a great collaboration feature in its own right, enabling expertise across the internal or external community to be brought to bear on posts structured as questions, with specific functions for answers, mark-as-best etc. As the name implies Question-to-Case allows a question to be escalated to a case from within the feed, with the feed post marked visibly as such.

Q2C1

Q2C2

Q2C3

A further extension to this feature, Knowledge Deflection for Chatter Questions is currently in beta. The functionality of this should be evident.

3. Action Links (GA)
Buttons can be added to feed posts that download a file, access a web page or call a 3rd party API. Action links can be grouped within an Action Link Template and packaged for ISV distribution. Action links are functionally very interesting, given the use cases they open-up, however the implementation is non-trivial and warrants a follow-up post.

It’s interesting to see how the Chatter product continues to evolve release-on-release. The direction the product is taking appears sensible, i.e. finer grained control via increased Trigger coverage (custom moderation etc.), richer content previews and extended external integration capability. Top of my wish list incidentally would be an enhancement to Topics to allow post activity from associated records (Topics for Objects) to be automatically shared and pushed out to topic followers via digests. This could be an optional flag that marks the topic as aggregating. With this model, users can simply follow a topic and have content pushed to them proactively that is either directly related (feed post association) or indirectly (feed post against an associated record). Such a feature would really help transition many notification use cases from email/task to Chatter.

Salesforce Manager Groups

A fit-for-purpose sharing architecture is one of the fundamental elements that underpin a secure and performant Salesforce implementation. The sharing architecture defines the record-level visibility model and should be subject to periodic review and refinement to reflect shifting organisational factors. The most efficient sharing models make full use of implicit sharing via the Role Hierarchy, with minimal use of explicit techniques such as Sharing Rules. An implicit model is reliant on a well conceived Role Hierarchy that reflects data access across the organisation, and is therefore not necessarily aligned directly to the organisational structure. This is hard to achieve and requires an approach of continual adjustment throughout an implementation project and beyond. The benefits of this approach are manyfold; control, reporting, maintainability and performance being just examples. In regard to control, implicit access provides the record-owner level of access, which can’t be achieved via explicit means. With reporting, the dynamic filters “My Team’s Accounts” etc. are based on the Role Hierarchy, i.e. users in roles below the current users’ role etc. in addition with some reports the Role Hierarchy can be used to filter the output at runtime. In regard to maintainability, the proliferation of sharing rules often introduced to compensate for a substandard Role Hierarchy design is avoided. Finally, in the performance case, although sharing data (AccountShare etc.) is persisted at the time of configuration, and not calculated fully at the time of record access, there is still a performance consideration with complex sharing models. So in short, a sharing model that is predominantly implicit is better than an explicit model. Irrespective of whichever model is implemented, a comprehensive understanding of the explicit techniques and their primary use cases is important to ensure the sharing model is appropriately secure and maintainable.

For the first time in a number of releases, the Spring ’15 release introduces a new sharing model feature “Manager Groups”. This feature extends the capability of explicit sharing techniques (Manual Share, Sharing Rule and Apex Managed Sharing) enabling direct use of the management hierarchy, as defined by the Manager field on the user record. Manager Groups are system defined, per-user, and can be utilised in the same way Public Groups are used in the same contexts. For each user 2 Manager Groups are provided; “Managers Group” – immediate managers and their manager and so on (up the management hierarchy) and “Manager Subordinates Group” – the user’s direct reports and their reports and so on (down the management hierarchy). Unlike Role Hierarchy based sharing, Manager Groups share directly to each user in the hierarchy chain, not all users with the parent role.

Note, the Manager Groups feature was initially introduced in the Winter ’14 release and made available upon request. Spring ’15 makes the feature automatically available in all orgs.

Prior to the introduction of Manager Groups, sharing based on the management hierarchy relied upon the Role Hierarchy reflecting the management hierarchy, or elaborate explicit means. The Manager Groups feature now provides an efficient means to share data up and down the management hierarchy, leaving the Role Hierarchy to strongly model the data access requirements for the organisation.

Enable via Sharing Settings page

Manager Group Sharing - Settings

Manual Share

Manager Group Sharing - Manual Share

Sharing Rule Definition

Manager Group Sharing - Sharing Rule

References:
Sharing Records with Manager Groups
A Guide to Sharing Architecture
Designing Record Access for Enterprise Scale
Record-Level Access: Under the Hood

Implementation Guiding Principles

In most cases software implementation projects start off with a clear vision of the various macro-level influences, constraints and directives that define the shape of the project at the outset. During the initiation stage the clear, consensus view on the project principles influences fully the micro-level decisions taken in terms of architecture, solution design, resourcing, scope, prioritisation, schedule and so on. The challenge for many projects is maintaining the purity of the vision across the course of the project in light of variations in uncontrollable factors such as the business context, risks becoming reality, project resources and so forth.

An effective tool to mitigate this loss of identity and direction, and the consequential impact this can have on confidence and productivity, is the definition of an unambiguous, concise set of guiding principles that are communicated early and frequently. Additional to the benefits related to a clear and strongly defined direction, principles support increased productivity through empowerment; if low level decisions align with the principles then action can be taken without time-expensive consultation.

Corporates do this, why not projects?
This approach is well established in business, with many corporates defining an aspirational, future state vision and set of guiding principles that underpin the delivery of the vision through applied influence to all activities undertaken and decisions made. Guiding principles can be very effective particularly where a culture is established that prioritises all actions taken in relation to their conformance to the principles. This level of application requires absolute confidence across the business that the principles are current, meaningful, complete and beneficial to all parties. The value of this approach at a business level can apply equally to a project.

Key Points
No more than 7. The primary value of guiding principles is the strength of the message, achieved through brevity. Telephone numbers were originally set at 7 digits as this was believed to be the most people could be expected to remember. 7 therefore seems a reasonable limit in this context.

Revisit during retrospectives. Stale principles will damage the integrity of the approach. Agility should be paramount such that principles are current and enable changes in the direction of travel whilst the project is in flight (excuse the metaphors here).

Communicate frequently. All project artefact (slides, documents etc.) should state the guiding principles and relate the content to the relevant principles, noting deviations.

All design decisions should relate to one or more principles. See above point.

Prioritisation. A simple prioritisation scheme (high, medium, low; 1,2,3 .. n) can be effective in resolving conflicts between principles.

Buy in. All project stakeholders must approve the principles and accept the impact. Without complete buy in the integrity of the approach is diminished.

Principles can be goals. Principles are often directive in nature, goals are an interesting extension to this.

Use Work.com. The Goals functionality of Work.com can provide a useful tool to manage, communicate, collaborate and report on the principles. This functionality also enables user-level goals to be mapped to the higher level goals.

Alternatives
Vision statements can be difficult to articulate, particularly where there are multiple unconnected concerns.

Project charters can be too cumbersome to be a realistic communication tool. It’s human nature to read once and subsequently ignore any project documentation that requires a time investment.

In both cases above, guiding principles can provide a complementary abbreviated formatting.

Examples
Maintainability of the solution by client administrator.

Future extensibility without technical resource.

Sales productivity improvement is the key objective.

Declarative build over technical solution options.

Quality over expediency.

Technical excellence.

Buy over build.

Alpha 1 bug count must be less than 100.

The solution will be productised internationally.

The project delivery date must be achieved.

Release early and iterate.

Business utility to be delivered every 2 weeks.

Only user-accepted features to be released.

User stories estimated at 5 days or more to be split.

Salesforce Spring 15 Platform Highlights

With Christmas a distant memory (well almost) it’s time to turn our attention to the next big event on the calendar, and no not New Year, I mean the Spring ’15 release of course.

The key dates for the Spring ’15 release are outlined here, the detailed rollout schedule can be found in the usual place.

The preview Spring ’15 Release Notes are here. Note, to keep up-to-date with updates to the release notes follow @salesforcedocs

This post outlines selected highlights related to the Force.com platform (in no order of significance).

– features are GA if not indicated otherwise

Salesforce1 Reporting Notifications
On the “Report Run” page a Subscribe button now appears that enables end users to subscribe to notifications relating to the metrics provided by the report, i.e. KPI1 greater than 100, send an email etc. Notifications can be scheduled in a flexible, recurring manner with the resultant action set to a Salesforce1 Notification (via the mobile app), Chatter post, email notification or Custom Action. In the latter case an Apex Class can be introduced which implements the Reports.NotificationAction interface.

public class myReportAction implements Reports.NotificationAction {
    public void execute(Reports.NotificationActionContext ctx){
        // perform action.
    }
}

The class above appears as an option for the “Execute a Custom Action” selection on the “Subscribe to..” page.

Report Subscribe

@testSetup Method Annotation
Test setup methods create test data for the test class as a whole. Annotated methods are executed first during test execution to create the test records – each constituent test method gets access to the same original set of records regardless of the DML operations of preceding test methods. This approach removes the test data creation and rollback operations from individual test methods, thereby reducing test execution time and removing the consumption of governor limits within test methods due to test data creation.

Mapping
Standard address fields now support inline map presentation. This is configurable and limited to Google as a map service provider.

Mapping - Standard Address Field

New Visualforce mapping components (apex:) make use of this capability to enable the simple addition of interactive JavaScript maps to Visualforce pages.

Lightning Process Builder
The Lightning Process Builder is unavailable during the pre-release programme, however the product will be GA on release. My general interpretation of the positioning of the 3 platform workflow capabilities is provided below for information only.

– Workflow: single-object centric collection of ungrouped rules and actions, auto-invoked via data modifications.
– Visual Workflow (Force.com Flow): multiple-object business process orchestration involving user interface elements for data capture and manual-invocation of logic*.
– Lightning Process Builder: single-object centric, visual composition of multi-step processes, auto-invoked via data modifications. Records can be created and cross-object updates applied to any related records not just the parent in a master-detail relationship.

(* I’m ignoring Flow Trigger Workflow Actions here; the pilot for which has been superseded by Lightning Process Builder.)

Note, there are differences between the beta version of Process Builder and the GA release. For example, Apex code can now be called directly from a Process, and Processes can be versioned for change tracking purposes (up to 50 versions, but only 1 can be active).

Login Forensics (Pilot)
Two new standard objects LoginEvent and PlatformEventMetrics enable identification of suspicious login patterns, such as unusual login times, IP ranges, above-average login behaviour etc. To avoid fraudulent activity a Salesforce security plan should be proactive in auditing login patterns over time.

Named Credentials
Named credentials bundle together the configuration details for an authenticated Apex callout; endpoint, authentication type and credentials are stored together as a single configuration record that is maintainable via the setup menu. This replaces a common use of Custom Settings and usefully decouples the authentication coding, which is handled by the platform.

Queueable Job Chaining
Asynchronous tasks submitted via Queueable Apex can now be chained an unlimited number of times; previously the limit on the chain size was 2. This sounds useful in terms of incremental processing of large data sets, but if your technical solution design requires a significant chain size this may indicate a flawed approach. Note, the release notes suggest that DE and trial orgs are limited to a chain size of 5.

New Lightning Components
New components and events have been added to the Lightning Component Framework, the restrictions in regard to authoring of components in a Developer Edition org with a namespace have also now been removed. With Spring ’15 components can be configured to run within the Lightning App Builder and Lightning Pages, although the former remains in a closed pilot.

Case Feed Macros
Case Feed users can now reduce time performing repetitive tasks by executing, via a single-key click, pre-defined macros. Macros are comprised of instructions such as selecting an email template and sending an email to a customer. In practice a library of useful macros will greatly increase Support Agent productivity whilst ensuring standardised support processes are adhered to. The macro functionality seemed to be missing from my pre-release trial org – I suspect the functionality is related to the Lightning Process Builder which is also omitted.

Indexed Column Added to Lists of Fields in Setup
A very useful additional column on the Fields page for Standard and Custom objects – covers standard and custom fields. An understanding of the indexes applied to an object can be key to troubleshooting reporting performance issues or to ensuring SOQL queries, list view filters etc. are defined with data retrieval performance in mind.

Indexed Column

Salesforce Activity Sharing

This brief post serves to clarify the sharing model related to Activities, i.e. Task and Event. For most implementations a public sharing model for Activity is highly appropriate and a necessary element of the CRM process. In some cases however a private model is required, perhaps where strict visibility rules must be applied in respect to Account and Contact, or where the activity itself is of a confidential nature. In the former example details of the Contact (Name, Title, Account Name) are revealed on the Activity record to assigned users (and those above them in the role hierarchy) who don’t necessarily have record visibility to that Contact or Account. This can be a problem. In the latter example, the interpretation of private OWD for Activity relates to editing of records, not visibility of records (as is the case for other objects) meaning there’s no mechanism to restrict access selectively to Activity records related to a given record. In mitigation, field level security (FLS) can be applied to hide fields from certain users, this approach can be effective but is not ideal. As such the implementation of a fully private sharing model for Activity can be difficult to achieve.

Blog Sketches

Activity Org-wide Default Implications
— Private : Read access to the [Related To] record provides read access to the Activity. Only the Assigned User and users above them in the role hierarchy can edit.

— Controlled by Parent : Read access to the [Related To] record provides read access to the Activity. Edit access is possible for the Assigned User and users above them in the role hierarchy, or requires [Modify All] object level access on the related record object, or the Modify All Data permission.

In considering the OWD settings above, the rules below must also be understood.

1. Activity Visibility. If the Activity is related to a Contact, then View access is required to the Contact, with the exception of the Assigned User (and role hierarchy) who can view the Activity regardless of Contact access. Private contacts can be problematic in this context.

2. Activity Edit. If the Activity is related to a Contact, then Edit access is required to the Contact, with the exception of the Assigned User (and role hierarchy) who can edit the Activity regardless of Contact access.

References
Help and Training – Access to Activities and Calendars
Idea – Support for fully private (no read or write) activity sharing model

Salesforce Topics

One of the more interesting (but low-key) functional enhancements to arrive on the Salesforce platform over recent releases is Topics.

All Topics Page

A Topic can be viewed as a consolidation of the collective enterprise intelligence around a specific term or theme, across both the collaboration dialogue and the business processes managed within Salesforce. In practical terms this translates to Chatter posts and Object records being assigned one or more new or existing Topics. All assigned records and posts then display on the Topic page – providing the consolidated view of everything happening across the enterprise that pertains to the Topic. This is incredibly powerful in terms of both data categorisation and the insight possible from considering the holistic view of a contextual theme or initiative.

Topic Page - Feed tab

The Topic functionality doesn’t end there; from a Topic page (see screenshot above) it is possible to endorse users as experts on the Topic thereby harnessing knowledge within the enterprise and providing an effective means of channeling communication such as a questions, suggestions and so on. Note, users can elect to remove themselves from the Knowledgeable People list.

Topics can be followed (if feed tracking enabled for Topics) and favourited which enables interested users to be updated proactively. Discussion of Topics is tracked at the Group and User level, the Chatter tab also shows the Trending Topics area which highlights recent activity, this excludes Topic used solely in private Groups or record feeds.

Note, as a point of clarification Topics differ from Groups in that they collect posts from across Chatter and also records.

Primary Use Cases

1. Topics provide a good solution option for any data categorisation or notification requirement relating to enterprise-wide initiatives or themes.
2. Topics map well to Organisational concepts such as departments, virtual teams, projects etc.
3. Topics could provide a useful (albeit elective) notifications model where the Topic feed is used to push notifications to users interested in new transactional records related to the Topic theme, which could represent a reference data type such as a region, product or channel.

Key Considerations

Topics for Object. Once enabled for an object, records can suggest Topics based on the values in selected fields. Whilst a Topic has a feed, record assignment does not generate a post. To mitigate this, Topic assignment can occur via #hastag in a post to the record feed. Additionally, feed activity related to a record is not viewable on assigned Topic pages. The concept relates to grouping and categorisation of records, not consolidation of feed items.

Global Search enabled. Topics appear as a distinct Object within the Record search results.

List Views. Topics can be referenced in List View filter criteria.

Reports. With Winter ’15 the reporting options are limited to those below (to my understanding) via CRT. Reporting on record level assignment isn’t there as yet.
–Topic – list of topics with # talking about statistic
–Topic Assignment – count of assignment per record type (key prefix)

Knowledge Articles. Topics can be added to Knowledge articles enabling end-user categorisation of published articles in addition to pre-defined data categories.

Customisation. Apex triggers can be defined on the Topic and TopicAssignment (assignment of a topic to a FeedItem or a record) objects, which are also API accessible.

Permissions. Profile permissions (or permission set) control who can create, edit, delete and assign topics. Defined topics are public regardless of whether they are solely used in private groups or on records.

Topics for Objects – Screenshots

1. Add a Topic to a Record

Add Topic to Record

2. Topics Assigned to a Record

Record with Topics

3. Topic Page – Records Tab

Topic Page - Records Tab