Archive for category Architecture

Don’t let your Salesforce.com Implementation Program lose Momentum

Salesforce Implementations can get seriously bogged down after a year or two of haphazard evolution

Salesforce Implementations can get seriously bogged down after a year or two of haphazard evolution

Is progress with your Salesforce implementation program becoming increasingly challenged? 

Symptoms include:

  • Project delivery late and over-budget
  • User adoption decreasing
  • Data quality decreasing
  • Minor changes taking too long to move from idea capture to delivery
  • Stakeholders preoccupation with stabilising the mess rather than taking strategic next steps
  • Salesforce staff failing to be retained

Whilst these symptoms are all too common with larger Salesforce implementations made complex due to the number of business units and system integrations, the good news is there are steps you can take to stay (or get back) on-track.

Make these practical decisions at the start a Salesforce implementation program to ensure you don’t get “stuck in the mud” or perhaps “Stuck in the cloud” should be the modern phrase!

  1. Establish a “Centre of Excellence” to govern change
    – centralise decision making, release management and design standards;
  2. Establish strong product management involving business and IT to assess and prioritise requests for change
    – ensuring high priority/value requests are delivered first;
  3. Stay ahead of the curve with strategy and architecture
    – communicate a clear (regularly refreshed) vision explaining where you are heading and how you will get there;
  4. Use a consistent delivery team
    – yield better results with an agile team working through a regularly re-prioritised backlog to avoid loss of staff continuity across a series of larger stop/start projects;
  5. Deliver releases regularly (continuous delivery)
    – be responsive to change requests (at least for minor enhancements) to keep users engaged as they receive increasing value as the platform is advanced;
  6. Keep documentation current
    – capture the reasons why decisions were made and what outcomes were achieved to inform the future;
  7. Develop a library of test classes/methods which simulate and test critical business functions
    – ensure nothing breaks as changes are deployed using automatically run test methods;
  8. Continuously focus on data quality at the point of entry
    – be clear for all data about why it is needed, how it will be used, and what defines “good data”;
  9. Make an ongoing investment to resolve legacy implementations which are causing problems
    – avoid an increasing pile of “technical debt” which will eventually inhibit progress;
  10. Learn as you go and invest in training
    – improve delivery over time by conducting post-implementation reviews;

If you need help with Salesforce please get in touch with Artisan Consulting.  Artisan provides a cost-effective Salesforce Program Health Check which documents your current state, where you want to get to, and provides practical recommendations for your next steps.

About the Author
Richard Clarke is a Program Director and Technical Architect within Artisan Consulting's Salesforce Delivery Team.  Richard has led Salesforce delivery teams in the Australia, New Zealand and the USA and applies over 20 years of enterprise software experience when delivering business value with Salesforce.com.

No Comments

Salesforce (Data) Relationships Matter

The ability to maintain data quality is dependent on establishing the right relationships between objects and configuring appropriate controls over data entry.  Too often this only gets the focus it deserves a year or two after Salesforce is implemented when data quality is poor and causing problems with reporting, integration or workflows.

Salesforce Data RelationshipsThere are two types of relationships available to connect objects together (master-detail and lookup) each of which has further options.

Chose the relationship type which best represents the real-world relationship between the business concepts the objects mirror then apply the tightest options possible to control over data quality.

Don’t add relationships to objects until you fully understand the choices available!

Master-detail (parent-child) relationships

This is always a required relationship as detail records don’t have an owning user and access control is managed at the master level.  When a master record is all related detail records are deleted as well.  There can be no more than two master-detail relationship in an object and only one if the object is the master of another relationship.  Standard objects cannot be detail records and Leads/Users cannot be master records.

There is an option to allow users to change the parent (master record) of a detail record.

A master record can have no more than 10,000 detail records.

Lookup (cousin) relationships

This relationship is not automatically required and has no effect on record access.  If the relationship is set to be required a record can’t be deleted if other records are related to it.

If the relationship is not required you can choose whether to prevent a record being deleted if other records are related to it, or to allow deletion by automatically clearing any lookup relationships. 

Setting a lookup to be required has a significant impact when creating a partial copy sandbox which contains objects with more than 10,000 records.  The partial copy sampling process will retain relationships which are required hence the related record will be copied as well.  If the lookup is not required then values can be lost from lookup relationships during the sampling process.

Filtering relationships

Applying an active filter to a relationship means when the user searches for a related record only those which match the criteria will be presented.  An active filter which is required cannot be bypassed.  An active filter which is optional can be bypassed.

An object can have no more than 5 active filtered relationships.

Validating relationships

Applying validation rules to a relationship can be used to check (when the record is saved) that a related record meets specific criteria.  This can be helpful if you hit the limit of 5 active filters as the limits on validation rules are higher (20 per object in Professional Edition and below, and 100 in Enterprise Edition and above).  Validation rules are also more powerful and more flexible that lookup filter criteria.

Active filters provide a better user experience than validation rules as they limit the records able to be selected, rather than allowing records to be selected then blocking the save.

Hints to guide selecting the right relationship type

  • If a record cannot exist by itself and access is controlled by the parent use master-detail.
  • If a record cannot exist by itself but has its own access controls use a required lookup.
  •  Use active filters if it does not make sense to allow connection to any record.
  •  Use validation rules to limit which records be related if there are already 5 active filters.

References

Limits – http://resources.docs.salesforce.com/198/17/en-us/sfdc/pdf/salesforce_app_limits_cheatsheet.pdf

Cheat sheet – https://resources.docs.salesforce.com/200/latest/en-us/sfdc/pdf/salesforce_filtered_lookups_cheatsheet.pdf

Lookup Filters – https://help.salesforce.com/HTViewHelpDoc?id=fields_lookup_filters_notes.htm

 

No Comments

Should Technology Solutions deliver Perfection or Pragmatism?

In my view senior IT leaders (CIO/CTO/Enterprise Architect) need to moderate their drive towards a perfect technology landscape with commercial pragmatism.

A target end state should be in clear view, and each project should be a step towards greater flexibility, improved performance, increased automation and reduced total cost of ownership. 

But perfection is best attained gradually rather than with giant strides.

Consider these two chairs – the fine piece may well be better furniture – but a pragmatic commercial outcome which balances budget, timelines, resources and required results may well be the other.

Chairs

I’ve seen too many projects founder by failing to deliver a business case with an acceptable return on investment, or failing to deliver a complete solution by deploying quality parts but a compromised whole.

If a business needs a working chair it is best to deliver the right hand option, rather than just the legs of the left due to delivery constraints.  Temper the striving for perfection and avoid being overly ambitious with the size of step change or being overly aggressive with the timeline.

A priority for a technology architect is to understand the blueprint and ensure projects are aligned to IT strategy.  How large a step a particular project should take on the journey from current state to future state is a commercial decision which needs pragmatism applied.

I vote for function over form in most cases and ensure solutions get the job done whilst also being a step in the right direction strategically.  And in that context a good customer experience is primarily about function.  All projects need to avoid looking pretty and performing poorly.

Achieve perfect function with patient progress and commercially moderated small steps.

This approach will also reduce the risk that your crystal ball view about which components form the ideal end state technology landscape is less than perfect and needs to be adjusted along the way.

No Comments