Update on CRM Architecture

Over the last month, the CRM Architecture Team has made progress in various areas to address stress points and to prepare for the projects slated to begin in the near future. Items of note include a process for:

  • requesting and receiving support from the CRM team
  • streamlining manual tasks related to provisioning access to the CRM
  • the removal of legacy components
  • the creation of a code review process for developers

These items fit into a checklist for successfully implementing large projects and ensuring smooth release management for their various deployments by ensuring detailed plans around the “4 Ps”: release plan, install plan, validation plan, and communication

One of the key requirements for the successful implementation of a project is access to support for the clients that work with the deliverables on a daily basis. The support model mirrors the one used by the OutSystems rapid application development platform. An automated process allows the sending of an email to create a ticket that is assigned and addressed by the CRM team as a whole.

Another aspect of this operational lifecycle after project completion is the need to grant and otherwise adjust access for users as roles and responsibilities change, while protecting the trust our customers have placed in securing their data. A few projects have been proposed that would allow the University Data Stewards and Security Administrators to have visibility into reports enumerating the access levels down to a granular level, as well as automated process that will reduce the amount of time spent waiting for changes to take place after approvals have been received.

To streamline development efforts, a process to assist all parties creating new functionality in Salesforce has been proposed: a code review process. This review process sets in place a checklist based on best-practices from Salesforce and the shared experiences of the CRM teams that ensures the project is easy to maintain in the future, and makes the best use of the metered resources in the org.

Bringing these efforts together are the 4 Ps.

  • The release plan creates a map of the project’s timeline using estimated dates indicating when key features will be deployed for testing and for production use, allowing for those dates to eventually be placed on the CRM change calendar as they become firm
  • The installation plan coordinates all the components that make up a project—such as apex code, Visualforce pages, and custom objects—and their journey from sandboxes to production
  • The validation plan lists the steps the various parties need to verify to confirm the project is working as expected and that all the components were migrated completely, each time an installation is completed
  • The communication plan ensures that the functional owners and target audiences are aware of the project, its various milestones and deployments, and are able to better plan its usage

Finally, some behind-the-scenes efforts include removing some legacy components from our org to make way for the Higher Education Data Architecture (HEDA) framework, that will be investigated as a potential foundation for future process and data integration projects. This framework provides the data structures that are specifically designed for Higher Education customers.

POSTED: Tuesday, December 5, 2017 02:00 PM
Updated: Saturday, December 3, 2022 01:02 AM