Why rushed projects/code doesn’t save time and reduces quality

The idea for this post came when I was driving and listening to the Zen and art of Motorcycle maintenance.

The book is full of interesting questions and will make you look at the world and has some fantastic concepts

It unsurprisingly talks quite a bit about Motorcyle maintenance, which I thought would be boring (I’m not a fan of maintenance with my soft developer hands). One part of the book focuses on how a  mechanic fixes a motorcycle, he doesn’t see the bike as a physical set of tires, metal, etc, he sees it as a whole set of logical systems all linked together. So when the mechanic is fixing a the physical chain, he is fixing the theoretical mechanism which is used to move the wheels.

Quality

A recurring theme in the book Zen and the art of Motorcycle maintenance is Quality, it devotes many pages to it.

Here are a couple of good quotes from the book

“The place to improve the world is first in one’s own heart and head and hands, and then work outward from there.”
― Robert M. Pirsig, Zen and the Art of Motorcycle Maintenance: An Inquiry Into Values

Quality tends to fan out like waves.

ROBERT M. PIRSIG, Zen and the Art of Motorcycle Maintenan

You can read about Quality as mentioned in the book by clicking the links below

Pirsig’s metaphysics of Quality

Quality (philosophy)

Whilst listening about quality, I got the idea for this blog post and I pulled over on the hard shoulder and started scribbling in my one of my many super hero notebooks (this one was amazing spiderman)

Alternative titles and quality

The title of this blog post could have been any of these and it will give you an idea of what the blog post is about.

Rushed projects lead to technical debt
Rushed code = Poor Quality code
Quick projects cost you time later
Why quality is important
more speed less quality

The blog post started on the topic of rushed code and rushed projects create the same amount of code but the rushing part reduced the quality of the code and customizations.

It became clear to me whilst writing, it wasn’t due to the speed of the code but the quality of the code was reduced due to the development processes which were omitted.

Rushed Code and Customizations

I’m 99.9% sure all CRM developers and any other developers have had to create some rushed code at some point. Let’s define what I mean when I refer to rushed Code/customizations and projects

Rushed code/customizations/projects involve knowingly missing out steps to deliver the project in a shorter time-scale.

rushed code (usually implemented in rushed project) will miss out steps to deliver code quicker

The assumption made by a lot of project manager/customers is they can remove parts of the development process without reducing the quality of the end product.

The key question is what parts of the development process are removed, to answer this we need to understand the steps in CRM development

1. Gather requirements
2. Design architecture
3. Design code
4. Write code
5. Test code via unit tests
6. Peer review
7. System Test (GUI)

The goal of the process is deliver the functionality, creating a solution which is as simple as possible with the fewest bugs

Why simple as possible?

I have written about why code complexity is a problem before in the blog post The problems with complex code and complex CRM Customizations

The benefits of Simple code and customizations are
Simple to read and understand
Simple to maintain
Simple to extend
Simple to debug
Simple to test

If you replace the word simple with the word quicker or easier, this explains why simpler code and customizations are so beneficial

The opposite of simple (in my mind) is complex code, below are some of the problems caused by complex code

• difficult to read and understand the code
• hard to test
• difficult to debug
• tricky to maintain and extend
• hard and sometimes impossible to test
• So what steps get removed

The steps most commonly removed from the development process are usually the parts of the process which don’t involve creating customization and code.

• Code Design
• Unit Test
• Testing
• Refactoring
• Peer review

As you can see all the non-code parts are removed because the project manager/customers cannot or have chosen to ignore the difference between good code/customizations and bad code/customizations but are merely judging the end product by number of lines of code/number of customizations.

Why are non-code processes removed?

Customers/Manager believe developers are only really working when they are writing code or creating customizations, I’m not quite sure where this idea came from but here are my best guesses

• When developers first start developing (particularly if self-taught) they start learning by creating code. Inexperienced developers believe developing is writing code and do not yet understand the value of the non-code related parts of development.
• Code/customization is the end product, so the shortest amount of time creating this must be the most efficient uses of the developer
• Some developers do not enjoy or see justification for the non-code writing parts of development and don’t do them

It’s a question of quality?

This strikes me as similar to someone building a house but instead of planning and designing the house they just get straight out and start putting down bricks. The end product would be a house but is more likely to be a house which could be huffed and puffed down by a big bad wolf.

When/why is rushed code and customizations

rushed code/customizations are created when things have to be done quick, the kind of estimates which leave enough time to create the code/customizations with no provision for design or things going wrong

Here are the common causes of rushed code/customizations and projects or reasons for missing out development stages

• Emergency Fix
• tight/impossible project deadline
• Change request
• Quick/Dirty fix
• Poor development processes
• inexperienced developers
• Lazy/poor developers

I originally attributed the removal of development stages to projects/customizations being rushed but it occurred to me the non code development steps are also willing removed by some developers. These developers are usually either inexperienced or poor/lazy developers.

A developer who believes he can write code with little design and no peer review or unit tests will create poor quality code more often than they create good quality code – Hosk
What motivate rushed code/removal of development steps

I will refer to the removal of development steps as rushed code, even though this happens sometimes by choice and not under time constraints, the end result in my eyes is rushed code.

There are two key types of people who create rushed code

Customers
Lazy developers

Customers will often push for short time-scales, going against the estimate and advice of developers.

Lazy/poor developers will rush the code because they do not want to either spend time doing a proper code design or often don’t like writing test units or other developers peer reviewing their code.

You can understand the initial logic of customers believing projects delivered in a shorter time scale must be better value.  The customer and the project manager can pat themselves on their backs at getting more for less.

It’s my belief they should be kicking themselves up the backsides because by rushing projects you generating poorer quality projects, which will be a lot more difficult to maintain and debug and likely to contain more bugs.

It is a known practise for some companies to lower bids for projects but the only way they can deliver projects at lower costs is by spending less time creating the code.  Less time spent creating code means the removal of non coding development process.  The consequence of removing the non coding but quality increasing development steps is a reduction of quality in the end product.

Reduced price = reduced quality

A lot of the time the cheaper version of a product is cheaper because the quality is reduced.  If you compare the Apple Ipod to the many cheap MP3 players (which look remarkably like the iPod) there is a difference in quality.  The cheap MP3 players are

• Feel cheaper
• break more easily
• hard to use

In this example you pay less and you get an inferior product, the quality of the product is reduced along with the price.

Rushed code I feel falls into the second category of reduced quality.  The main side effect of reduced quality is increased complexity and a lot of technical debt.

Why do customers ignore quality

When customers push for shorter delivery dates they are agreeing to creating a finished product of reduced quality.

This seems odd behaviour which the same customer wouldn’t do outside of work.  If this customer was getting a house built or hiring a plumber to install a boiler or hire a mechanic to fix their care.  Would the customer

• Would the customer hire someone who was really cheap but not very good?
• Would the customer get the job rushed and agree to corners being cut?
• would the customer allow the house to be built with minimal design and not testing of the house?

The question is why is this behaviour seen as ok with CRM projects, particularly when some CRM projects are big investments for companies.

I believe customers are judging the successful delivery of a project using the wrong criteria.  Projects should not be deemed successful if a version of the CRM project goes live by a certain date.

Successful projects should be judged by

• What functionality was delivered by the project
• How many bugs were found in the project
• Did the project release go without problems

For a CRM project launch to be successful it’s vital the project is released with as few bugs as possible and with key functionality included.  Early setbacks in a project or a disastrous initial release can stop the CRM software from being used by the end users because they can easily lose faith in new software if it’s full of bugs and doesn’t work very well.

A successful release of a CRM project will give the users confidence in the system.

If you get it wrong on the initial release of the CRM project, sometimes you won’t get another chance to win the users over.

Why Quality is important

Apple are a great example of quality products.  Most of the apple products (iPhone, iPod, iPad) are quality products which are easy and fun to use.  This quality allows Apple to sell their products for a high price because the user knows they are buying a quality product and they consumers are willing to pay more.

Quality in code is an interesting concept because CRM Developers can look at some code and in most cases will instantly know if it’s good or bad code but if you ask a CRM developer what are the characteristics of good code, they will stop and think and won’t be able to give you an instant answer.

The design phase of a project and design of code are probably the most important phase of a project and creating code.

The design and structure of code, will sort and organise the code in small simple parts.  This greatly reduces complexity of the code.

The simpler we can make the code the easier it will be to understand the code in six months time when our business knowledge of the code and the system has diminished.  When developer a CRM project, during the development the CRM developer will have very high levels of business knowledge.  The CRM developer will understand the code in detail  will understand the business requirements and rules of the customer.

When the development phase is finished and the CRM developer works on other projects but later works on the original project, the business knowledge and code knowledge of the system will have reduced.  If the code is simple, the CRM developer will easily be able to understand the logic of the code and enhance and debug the code.

If the CRM solution is complex the CRM developer needs the high level of business knowledge to understand the code, this is where rushed projects really suffer.

Rushed projects suffer from technical debt because the development processes which get removed

• Testing
• Refactoring
• design
• peer reviews
• documentation

The processes which get removed to save time (or the CRM developer can be bothered to invest the time) are all focused on the quality of the code.   The tasks focus on ensuring bugs don’t exist, the code is as simple as possible and can be tested.   All the processes reduce the number of bugs in the CRM solution and are designed to keep the code well structured and lean.

What does rushed code look like

Rushed code like its distant cousin bad code has a smell.  Code starts to smell when it isn’t right, learn more about code smells by reading the wiki article.

When creating code it’s a constant battle to keep the quality high and the code simple, as soon as the standards start to drop the complexity of the code will start to rise and any interaction with complex code takes longer.

You must control code complexity.  Uncontrolled complexity will drag the code down until no one wants to touch it.

Rushed code and projects is where less time has been spent on designing, planning, structuring the code, testing, reviewing and this will increase the complexity of the code.

Rushed code = greater code complexity

Here are some of the main culprits of complex code taken from here

• Large methods – Monster methods
• confusingly named classes, methods and variables
• methods which do lots of things
• not consistent
• tight coupling
• dependent code
• poorly structured code

The other sign of rushed code is no unit tests and a lack of documentation.

Consequences of rushed code

Quality manufactured goods last a long time and are usually a pleasure to use, the same is true for quality code.   Quality code is great to use for CRM Developers when they are reading/understand, debugging, maintaining and extending.

CRM Projects are expensive investments for companies so it surprises me they want to reduce the quality of the solution created because this I believe should the goal of the CRM development.  Create a high-quality CRM solution which delivers the required functionality and do it right first time.

I believe customers, managers and other people pushing for rushed code should be asked

What is the goal of the CRM project, is it to create a CRM solution quickly or is it to create a quality CRM solution.  Is it time or quality?  The person asking for the rushed code should also be made aware the time saved now should be reinvested later to bring ensure the quality of the CRM solution is kept high.  If the time is not put in later then modifying, maintaining, debugging and extending the code later will all take longer.

The person asking for the rushed code should also be made aware the time saved now should be reinvested later to bring ensure the quality of the CRM solution is kept high.  If the time is not put in later then modifying, maintaining, debugging and extending the code later will all take longer.

Borrowed Time

Producing rushed code is like taking a  short-term loan out, if you don’t pay it back soon then the interest will keep building up.

The currency used with projects and code is time.  Rushing the code will save you a bit of time now but the long-term effects of the rushed code will cost you more time later

Rushed code is like paying for a car using your credit card and then paying back the bill slowly each month. If you want to buy a car you should get a proper long-term loan out.

CRM projects do not seem like the place to want to cut corners and reduce the quality of the end CRM solution by rushing the project to shorten delivery times.  Particularly if the company plans to use the CRM solution for many years to come.

One of the key consequences of creating rushed code and rushed CRM Projects, is any further enhancements or code interaction will take more time and resources.

Rushed code and projects is where less time has been spent on designing, planning, structuring the code, testing, reviewing

The code will contain more bugs

The CRM Solution/Code will not be optimized and could run slower

The CRM solution will have increased complexity

You will have no tests to run against the code base, increased chance of missing bugs.  Unit tests are a valid way for new developers on the project to understand and step through code

Business logic

It’s important to create documentation and tests when you creating the project because you knowledge of the business logic (e.g. customer logic and code logic) will diminish the longer you spend away from the project.

No documentation and unit tests mean you have to relearn everything and this will be more difficult if the code has been rushed because it means the code will be more complex.

More Bugs

Rushed code will likely to include more bugs.  The reason for this is because no unit tests have been written (which can find bugs), no peer reviews of the code.

Bugs found later in a project will cost more time and effort to fix.  You can read the two discussion to find out more

Is it significantly costlier to fix a bug at the end of the project?

Software Defects – Do Late Bugs Really Cost More?

Without having statistical evidence it would seem to me bugs found later would take longer.  If you take into account the process of the customer raising and logging the bug, time to understand and then recreate the bug.  Bug hunting will probably be harder if the person hasn’t used that part of the system or knowledgeable of the code (e.g. not in the project zone).  Moving the code through all the CRM environments.  It seems logical that it’s harder to find bugs later on and then the fixing and promoting the bug fix into live will take longer the later you find the bug in the development process.

Technical Debt

Rushed code will have technical debt due to the short cuts taken to produce the code and customizations faster.

If you don’t know what technical debt is read this wiki article and it’s basically refactoring and changes which you owe the code/project.  Technical debt are code restructuring changes you have put on the list called TO DO Tomorrow.

Just like items you put on the TO DO tomorrow list, they don’t always get done, which means the technical debt keeps growing, which consequently makes tackling it a bigger and bigger problem.

Poor readability

When developers look at code they scan it to get an understanding of how it works.  Before you can debug or extend code you have to understand what it’s doing and how it works, this makes readability very important 

If you struggle to read the code, how the hell are you meant to fix it – Hosk

Rushed code can be inconsistent and complex because it was created quickly.

Summary

Rushed code or not creating the code and customizations using all the development steps will create complex code of reduced quality.

Working on rushed projects is not enjoyable, good CRM developers do not like creating rushed code and customizations of reduced quality.  It feels wrong at the time and hard to use later on.

When you create rushed code and customizations any time saved on the creation of the code will be lost when the code is worked on later.

When you create rushed code you are agreeing to create a CRM project of lower quality

Advertisement

CRM 2013 – Convert Email HTML to Plain Text

I have had this request from a few customers over the years and it’s converting and using the description of an email is trickier than you initially think it will be.  This is a question which often appears on the CRM forum quite regularly as well.

The reason for this is although the email looks like plain text when you see it in CRM, when you get the value of the Email entity description (main body of the email) you will also get all the HTML tags.

The scenario I had when I was doing this was the customer wanted to convert an email into a case and get the values from description.

So to do this I had to strip out the HTML tags and a few other things, which I did using a plugin

if you have to do this here a couple

This blog post is excellent

http://ashwaniashwin.wordpress.com/2014/04/16/convert-html-to-plain-text-for-copying-email-message-in-crm-2011-2013/

C# code

http://aliraza.wordpress.com/2007/07/05/how-to-remove-html-tags-from-string-in-c/

A sample plugin

http://blogs.msdn.com/b/ukcrm/archive/2008/07/10/converting-html-e-mail-to-plain-text.aspx

 

Recently I saw Steve Green had created a CRM Video going through the process and  I thought I would promote the video on the blog because he also has a link to the code here https://dl.dropboxusercontent.com/u/4041841/CRMDemo2014.zip

 

 

I would also recommend anyone who wants to learn CRM development to go through Steve’s other CRM videos, many of them are in CRM 2011 but the code would still work in CRM 2013.

CRM 2011/2013 Dialog’s and Custom Workflow example

I had piece of functionality I did at work recently and it had a few interesting parts, so I thought I would blog it down.  You can read the blog or watch the video

The required functionality required the ability to update multiple appointments, in this deployment we have created a new appointment entity called Client appointment but basically I needed to update multiple appointments.

The user wanted to specify a cancellation reason.

I was initial thinking of using a workflow and selecting lots of appointments but because they needed to specify a cancellation reason then this wasn’t an option

With input required a dialog seemed like a good option.

The problem I quickly found was Dialog’s can only be triggered on one record at a time and not multiple records like workflows.

Contact Dialog

So the plan was changed to be run on the contact.  I would have a dialog which ran on the contact entity the user would be prompted for a start date, end date and a cancellation reason.

I would call a Custom Workflow from with the dialog and pass selected values to it and then the custom workflow would do a query, select all the appointments, cancel them and then create a reschedule task and assign it to a reschedule queue.

I usually trigger code changes from plugins and wondered what circumstances would I move that code to be triggered into a Custom Workflow but this a good example.

This code isn’t really suitable to be triggered from a plugin because there isn’t anything being changed/updated or created so there is no natural plugin trigger point.

Thinking about this I can see that within certain workflows and dialog’s is the perfect place to call a custom workflow, particularly when nothing has been updated or modified and you want to trigger those changes and the changes are going to be complex which needs a code to do.  This is a good example because the code needs to retrieve a lot of appointments linked to a contact, this functionality couldn’t be achieved in workflow or definitely not easily.

After re-reading the requirements I noticed we needed to specify a start time and end time and this would also work in a slightly unusual manner.  If the user specified 08:00 to 12:00 with a start date and end date which went over more than one day.  The user wanted the morning appointments to be cancelled for each day specified but the afternoon appointments to be left alone.  This would provide a tricky piece of querying which I will go into later.

In theory this seemed like it would work, so I initially created a skeleton Dialog and a Custom workflow which logged the fields.

 

The first little problem I had was, how to show the time.  The choices I had were text single response, this would involve the user typing in the time, I didn’t like this option because it wasn’t easy for the user and had the potential for them to mistype.

The other option was to create an optionset with an hour value for each hour.  e.g. 01:00, 02:00 etc.  In then end I chose this option.

The user also wanted the ability to not select a time and this would mean they wanted to cancel the whole days appointments.

So I created the the optionSet with a default value of – Full Day and then 01:00 label would have the value of 1, 23:00 would have the value of 23.

 

SET THE CORRECT DATA TYPE

One mistake I made at this point was to incorrectly set the Data type to text.  This is a real schoolboy error because once you set this you can’t change it.  So I had set it to text gone through adding all 24 hours and then realizing and had to do it all again, very frustrating.

What is also very frustrating is the fact you can use an optionSet created in CRM, you have to copy the values again.  This means there isn’t any schronisation between the OptionSet in your dialog and entity.  It also means you may have to create the values numerous times in a dialog because you can’t reuse it in a dialog.

In this example I had to create the same OptionSet for start date and end date.  Tedious indeed.

 

The cancellation reason was the same kind of thing, I had to copy an OptionSet inside CRM and recreate it and give the OptionSet values the same as the values in the CRM OptionSet field, this way I could pass the value into the Custom Workflow and then it could use the value to set the OptionSet.

 

Warning Popup Message

When I did a demo of the functionality to the client, they said they would like a warning to pop up, if the dates specified were within 3 days.  The reason for this is if you cancel appointments with 3 days of today, it’s difficult to reorganize these so users should be certain they want to cancel these appointments.

Sometimes when someone asks you about how to achieve some functionality in CRM, you can be momentary stumped and can’t see how to do it and this was one of those moments.

I couldn’t see anyway to pop up a warning message.

It was only later that I was talking through the problem with the team that the obvious answer came to light.

Dialog’s are made up of pages and on each page you have a one or more prompt and responses.

So if I wanted a warning message all I needed to do was to create a new page, show the information the user had entered earlier in the dialog and ask them to confirm if they wanted to proceed with the changes using an OptionSet with Yes/No.

 

What I did was to check if the start date was greater than three days, if so put a confirmation page but if the start date was less than three days I would add the words warning.

 

Sensible variable names

This is the same for workflows but when you are adding conditions or adding steps/prompt and responses make sure you use easily understood variable names because later you will need to use these fields to update an entity/pass to a custom workflow so you need to be able to easily understand what each field is.

Here is the Custom Workflow being called from within the dialog

 

Below you can see the main code for the Custom Workflow, you can match it up with the screen shot above.  The actual code is in this class commonClientAppointment class

 

public sealed class CwaBulkAppointmentStatusChange : CodeActivity
{

/// <summary>
/// Gets or sets Min Wait Time
/// </summary>
[Input("Start Date")]
[RequiredArgument]
public InArgument<DateTime> StartDate { get; set; }

/// <summary>
/// Gets or sets Max Wait Time
/// </summary>
[Input("End Date")]
[RequiredArgument]
public InArgument<DateTime> EndDate { get; set; }

/// <summary>
/// Gets or sets Max Wait Time
/// </summary>
[Input("Start Time")]
[RequiredArgument]
public InArgument<int> StartTime { get; set; }

/// <summary>
/// Gets or sets Max Wait Time
/// </summary>
[Input("EndTime")]
[RequiredArgument]
public InArgument<int> EndTime { get; set; }

/// <summary>
/// Gets or sets Max Wait Time
/// </summary>
[Input("Cancellation Reason")]
[RequiredArgument]
public InArgument<int> CancellationReason { get; set; }

/// <summary>
/// Gets or sets Task Reference
/// </summary>
[Input("Contact")]
[ReferenceTarget("contact")]
public InArgument<EntityReference> Contact { get; set; }

/// <summary>
/// Executes the workflow activity.
/// </summary>
/// <param name="executionContext">The execution context.</param>
protected override void Execute(CodeActivityContext executionContext)
{
// Create the tracing service
ITracingService tracingService = executionContext.GetExtension<ITracingService>();

if (tracingService == null)
{
throw new InvalidPluginExecutionException("Failed to retrieve tracing service.");
}

tracingService.Trace("Entered CwaBulkAppointmentStatusChange.Execute(), Activity Instance Id: {0}, Workflow Instance Id: {1}",
executionContext.ActivityInstanceId,
executionContext.WorkflowInstanceId);

// Create the context
IWorkflowContext context = executionContext.GetExtension<IWorkflowContext>();

if (context == null)
{
throw new InvalidPluginExecutionException("Failed to retrieve workflow context.");
}

tracingService.Trace("CwaBulkAppointmentStatusChange.Execute(), Correlation Id: {0}, Initiating User: {1}",
context.CorrelationId,
context.InitiatingUserId);

IOrganizationServiceFactory serviceFactory = executionContext.GetExtension<IOrganizationServiceFactory>();
IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);

try
{

DateTime startDate = this.StartDate.Get(executionContext).ToLocalTime();
DateTime endDate = this.EndDate.Get(executionContext).ToLocalTime();
int startTime = this.StartTime.Get(executionContext);
int endTime = this.EndTime.Get(executionContext);
int cancellationReason = this.CancellationReason.Get(executionContext);
EntityReference contactRef = this.Contact.Get(executionContext);

CommonClientAppointment commonClientAppointment = new CommonClientAppointment();
commonClientAppointment.CancelHPAppointments(service, contactRef, startDate, endDate, startTime, endTime, cancellationReason);

}
catch (FaultException<OrganizationServiceFault> e)
{
tracingService.Trace("Exception: {0}", e.ToString());
}

tracingService.Trace("Exiting CwaBulkAppointmentStatusChange.Execute(), Correlation Id: {0}", context.CorrelationId);
}
}

 

Other interesting bits of code, below I set the start date to add the hours selected in the start time, unless it’s value is zero (which means whole day), which I then use the default time 00:00 and for enddate I give the value of 23:59 (e.g. the whole day)

if (startTime > 0)
{
startDate = startDate.Date;
startDate = startDate.AddHours(startTime);
}
else
{
startDate = startDate.Date;
}

if (endTime > 0)
{
endDate = endDate.Date;
endDate = endDate.AddHours(endTime);
}
else
{
endDate = endDate.Date;
endDate = endDate.AddHours(23).AddMinutes(59);
}

 

The other tricky bit of code was time specified code.  To recap if a time was specified then the appointments between the time should be cancelled on every day specified in the date criteria.  To do this I calculated the difference in days and then looped around that many times and added a day each time I went round  the loop.

e.g.

start date 01/01/2014

end date 07/01/2014

start time 07:00

end time 12:00

 

This would cancel all morning appointments for all the days (01, 02, 03, 04, 05 , 06, 07)

I had two options, I could either create one query with multiple date conditions or I could create one query and then repeatedly call this with the start and end date changed.

I couldn’t quite invisage doing one query so I called the query once for each day in the date range.

List<Entity> bookedAppointments = new List<Entity>();
if (startTime == 0 || endTime == 0)
{
//full days
bookedAppointments = CancelAppointmentsRetrieve(service, hpEntityRef, startDate, endDate, statusCode);
}
else
{
//time specified
int days = calculateDays(startDate, endDate);
int counter = 0;
DateTime loopEndDate = startDate.Date.AddHours(endDate.Hour);
while (counter <= days)
{
bookedAppointments.AddRange(CancelAppointmentsRetrieve(service, hpEntityRef, startDate, loopEndDate, statusCode));
startDate = startDate.AddDays(1);
loopEndDate = loopEndDate.AddDays(1);
counter++;
}
}

if (bookedAppointments != null && bookedAppointments.Count > 0)
{
this.UpdateBookedAppointments(service, bookedAppointments, cancelReasonInt);
}

&nbsp;
<pre>

 

 

 

CRM 2013 – Workflow to set the current date and time

This question has popped up in the forums now and again so I thought I would write a blog post on it.

The solution on how to do this is simple, once you know where to look and how it works.  I can understand why some people struggle to find the answer to the question of setting a date field to the current date and time because you don’t see it mentioned very often and it isn’t obvious.

To set the a Date Time value in CRM to a when the workflow was run you can use the dynamic value

Process

Execution Time

This basically does what is says on the tin and sets a Date time value to Execution time of the workflow.

Open up your workflow and choose the Update, select Account entity

To set a field

Select the field and in the example above, I clicked into the Account Date Field

In the look for I scrolled down to Process (it’s right at the bottom)

in the next field select Execution Time

Press OK

You will see the Account Date Field will now have a highlighted value.

Save and Close

Activate the workflow

CRM 2013 Video  Workflow to set date and time field and user when the primary contact on an account is changed

Awesome picture from here

Hosk’s Microsoft Dynamic CRM Development Youtube channel is up and shuffling along

I have decided to create a separate CRM Development channel and it’s up and running , so all aboard and hope on the Hosky Development Bus.  I wouldn’t get too excited yet because there isn’t anything useful on the channel yet, one video of me roughly and rather too quickly saying what the channel is going to be about and another of me mucking up trying to do that in my slippers!

To be honest this is just me practicing and getting my head round the process and the technology and taking a few baby steps in the right direction.  I will start with the more useful video’s next week and I hope you will join me.   Before you throw you hands up in the air and shout “what’s this?, this isn’t CRM Development Hosk you big fat liar”.  Please remember someone asked about me doing this on Monday, someone else on Tuesday, I created the LinkedIn group (please join up) on Tuesday, the YouTube channel on Wednesday and have been investigating software and webcams since then.

I would also suggest it will take me a few videos to get better at the process, for some reason as soon as the webcam starts you feel a plonker, thoughts change from coherent logic to random unrelated thoughts and at the moment my speech goes faster and squeaker!  But remember it’s not where you are but where you are going and I will improve with regular videos.

On a positive note I have been greatly encouraged by the comments made by people and the appetite people seem to have for a CRM development channel, this if nothing else will encourage me to produce some hopefully useful video’s.

So the channel is here

http://www.youtube.com/channel/UCtXD951oMDvJlmvwHCW5e5A

youtube also create a google plus page

https://plus.google.com/u/0/108763036087733529871/posts

Here are the video’s, you should get some idea that this channel is going to be Informal and often done in slippers

I thought I would add this video because it made me laugh and it’s always good to laugh on a Friday

Hosk’s Microsoft Dynamic CRM Development

A few people have suggested it would be a great idea if I started a youtube channel focusing on Microsoft Dynamics CRM Development.

I remember when I first started CRM development it was all a bit hit and miss and I there is not a great deal of resources to help.  Well that isn’t totally correct there is some excellent information in the CRM SDK but when first starting out this isn’t straight forward to getting working.

I also want to start doing some CRM 2013 development because I am currently working on a CRM 2011 project but I would like to get a bit of experience with CRM 2013 and so whilst I am doing this it would be a good idea to document this with a youtube screen recording.

I have created a Linkedin group – Hosk’s Microsoft Dynamic CRM Development so if you are interested please join up, I thought a group would be useful because it’s an easy way to raise discussions etc.  Currently there is an impressive 13 members.

I’m not really sure how this is going to work, if many people will find it interesting or what to include, I am not totally how to do it technically, I have been mucking around with some screen recording software and have had my face looking odd at the bottom right, fidgeting and looking like a bit of a muppet.  My main goal is to use screen recordings because I want people to see what I am doing and follow it rather than talking a bit and then showing a “here’s one I made earlier”.

Based on my current investigation the videos will be informal and scruffy (like a lot of developers) and to begin they will be short videos, at least until I get the hang of it.

My initial thoughts on what to include are (roughly) general CRM development

Plugins

Javascript

Developer resources/blogs

solutions

workflows

new CRM 2013 functionality

Forum questions

Development problems

Best Practices

Tools

Development Setup

For this to be useful I think feedback from people who are interested will be important, so you can either join the LinkedIn group, leave a comment here or I have created a new page which you should be able to see at the top of the blog

https://crmbusiness.wordpress.com/hosks-microsoft-dynamic-crm-development/

I will probably use my youtube channel rather than creating a new channel

Who know’s where it will go from here but I will need suggestions and help (send me some code you think is useful to everyone or even create you own video’s) because a group of people is always going to create something more useful than just one Hosk.

stay tuned to the blog and hopefully I will make a few baby steps next week