You can have plugin that fire on create of appointment. I have created a simple plugin and its working for for me. No fency coding. I can attach a debugger and place a breakpoint. If you look into CRM SDK install folder and go into tools folder and there you can find an excel file. That excel file lists all the plugin events available to appointment entity.

using System;
using System.Collections.Generic;
using System.Text;

using Microsoft.Crm.Sdk;
using Microsoft.Crm.Sdk.Query;
using Microsoft.Crm.SdkTypeProxy;

namespace testplugin
{
public class Class1 : IPlugin
{
public void Execute(IPluginExecutionContext context)
{
string message = context.MessageName;
string entityname = context.PrimaryEntityName;
ICrmService service = context.CreateCrmService(false);
string wfname = “”;

try
{
throw new InvalidPluginExecutionException(“Test Error”);
}
catch (System.Web.Services.Protocols.SoapException ex)
{
throw new InvalidPluginExecutionException(String.Format(“Exception with {0} during plugin {1}, with message {2}, {3}”, message + ” on ” + entityname, wfname, ex.Message, ex.Detail.InnerText));
}
}
}
}

Let me know, if you are still facing issues. Add me in your MSN or messanger.

I have moved the logic back to to a plugin as per your suggestion, and discovered the reason i went for w workflow.. haha

it just does not fire. i have attached it to the create appointment event, tried parent and child and messed around with everything i can think of.

if i attach it to another entity, it fires every time.

I have asked around the office, and another developer said he had the same problem with plugins on appointment creation, and was never able to resolve it. His solutionis now also in a workflow.

Any idea why? should i be using a different event instead of create?

Its a bad idea to generate autonumbers through workflows because they are async in nature. And we are creating a custom entity to carry the next autonumber.

Rather using a workflow, i advise you to use a plugin assembly, syncronous one and on post create event. Although it works fine most of the time but there is probability of error (non unique numebrs).

Why is workflows a bad idea? too much overhead?

Some background:

We are creating appointments enmasse from an external source. These need to be allocated a unique and human readable autonumber. these appointments are then propogated to an offline third party application.

This offline third party applicationcan also generate new appointments, which then get synced back to the server, althoguh these are far less as far as volumes go.

It made the most sense to therefore set an autonumber workflow to fire on appointment creation, redardless of the source of that appointment, to fill the autonumber field.

In the case of the mass load, this does cause hundreds of workflows to fire.

The appointments created in the third party application will therefore not have an autonumber allocated until those records arrive on the server, and these are then passed back to the that application in a subsequent sync.

it seemed the best way to ensure a unique ID across all records, regardless of their source, was to use a post create workflow.

It is critical that we do not duplicate this ID.

That said…

the problem have found this morning for the first time during the mass load, is that if one of these autonumber workflows freeze for whatever reason, then no other workflows fire, regardless of their function, across all tenants on the server.

So that would seem that the async service does not thread instances of workflows, but rather executes them sequentially. so the file lock is not really needed, and you could rather use a workflow and a custom Autonumber entity.

I am investigating Casper Jensen at CrmExtensions.com ’s free solution that uses entities and Mutex’s.

Though i would love to hear your input on this.

Generating autonumber through workflows is not a good idea. and using file locking will create issue while working in offline mode. It depends upon how you are designing deployements architecture for your crm implementation.

You are right that we cannt have 100% pure autonumbers. But if you are using CRM offline client then you dont have access to External DB and that created a deployement issue and hence a bad design. So i think its a job at design time to specify how we are going to generate autonumbers.