This post presents a basic model for the control of change within a Salesforce development process. Best practice suggests that all non-trivial projects should implement some degree of governance around environment change, i.e. Change Control. This is perhaps obvious, what isn’t necessarily obvious is how to achieve effective change control without introducing friction to the develop->test->release cycle.

In simplistic terms a change control process should ensure that all changes are applied in a controlled and coordinated manner. The term controlled in this context relates to audit-ability, acceptance and approval. The term coordinated relates to communication, transparency and orchestration of resources. The foundation upon which such control and coordination is achieved is accurate recording of changes and their application to specific environments, the object model below shows one approach to this.

Note, where feasible I recommend using the production org for this purpose, which may be challenging from a licensing perspective…

The biggest area of risk on any Salesforce implementation project is the data model. In my view this assertion is beyond question. The object data structures and relationships underpin everything. Design mistakes made in the declarative configuration or indeed technical components such as errant Apex Triggers, poorly executed Visualforce pages etc. are typically isolated and therefore relatively straightforward to remediate. A flawed data model will impact on every aspect of the implementation from the presentation layer through to the physical implementation of data integration flows. This translates directly to build time, build cost and the total cost of ownership. It is therefore incredibly important that time is spent ensuring the data model is efficient in terms of normalisation, robust and fit for purpose; but also to ensure that LDV is considered, business critical KPIs can be delivered via the standard reporting tools and that a viable sharing model is possible…

Nintex Workflow for Office 365 recently released the Salesforce Connector on Nintex Store which allows you to integrate your workflows with Salesforce easily.

Salesforce Connector

The pack contains these actions:

• Salesforce Chatter
  • Post Feed
  • Post File
  • Post Poll
  • Post Link
  • Send Invitation
  • Search Feeds
• Salesforce
  • Create Record
  • Update Record
  • Delete Record
  • Retrieve Record
  • Query Record

Salesforce Action List

In this post, we will discuss on how to configure each of the Salesforce Chatter actions.

Getting started:
You will need a registered account in Salesforce to fill in these details in each action:

• Username
• Password
• Security token

Tip: It is recommend to configure it with an account that doesn’t have password expiry so that you don’t have to revisit this section when the password has changed.

Salesforce credentials

Salesforce Chatter Post Message
You can use this action to post a message to your followers, group or specific user. The message supports…

In order to evolve as a country we learn how to make the way we do business more and more efficient everyday. Cloud computing is becoming increasingly important in most areas of business due to the advantage of having important information in a safe place that is also easily accessible to others in your company.

The retail industry is at the top of our list of those who are already using the Cloud. Most of us have experienced by now the speed at which offers are customized and sent to our e-mail in-boxes due to a previous purchase from a website. Products and offers are now being based off of our past purchases and used to provide better insight into our future needs. Efforts to predict the needs of consumers have seemed to increased  thanks to the use of predictive analytics within the Cloud. Retailers are clearly taking advantage of…

This assignment instructed us to choose a CMS of our choice and install it from scratch on our own server.  I bounced between WordPress and Drupal but ultimately decided to go with WordPress as it is the CMS that the majority of the classwork is based upon.

My CMS Choice

I currently use Amazon Web Services (AWS) as my hosting service, so there is no “1-click” installation option like many of the other hosting services provide for WordPress. Amazon has some pretty extensive help documentation however, and I was able to find  a listing that spelled out the steps involved.  It can be found here.

Steps Involved

Below is a summary listing of the steps it took to get WordPress installed and running on AWS.  Everything was done via command line interface using the PuTTy client.

• Downloaded and unzipped WordPress from wordpress.org
• Logged into MySQL
  • Created a WordPress database

Introduction: MFA

Multi-Factor Authentication as utilised by AWS uses a TOTP (Time based One Time Password) setup with either a hardware or ‘virtual’ MFA device. The virtual device being the most commonly used, allowing you to use applications like Google Auth on your smartphone to generate passwords that are only viable for 60 seconds.

This means that if you have MFA enabled, even if someone has your password, so long as they don’t also have access to your (hardware or virtual) MFA device, they’re unable to login to your account.

Introduction: AWS MFA

MFA as utilised by AWS is pretty straightforward to setup, scan a QR code, type in a couple of PINs, job done. So long as you have the right permissions.

In order to allow your IAMs users to even setup their MFA device you need to set a policy against their user (preferably indirectly using a group)…