Workflow scope and security roles

by | Jun 5, 2009

When creating workflows there are some things that have to be taken into account. One thing that you might not know the details about is the Scope in “Options for Automatic Workflows”. There are four options that are very similar to the options used for setting up security roles. They are:

– User
– Business Unit
– Parent: Child Business Unit
– Organization

Bellow the selection of the scope, there are some workflow triggering options, like starting the workflow when on create or when an attribute has changed.

The meaning of this is that dependent on the scope you have selected, the triggering will be set up, based on the user who owns the workflow.

So, for instance, if I select “User” in scope and then select triggering on attribute change, and I am the owner of the workflow, then it will only trigger when I make a change to the object.

If scope is set to Organization, it will trigger for all users in the tennant which is why this is most often used. Note however that user is set as default, so you’ll have to change this when creating the workflow if you want it to work for someone else than yourself.

This is a useful tool since it can allow powerusers to create their own workflows to help them with their work without actually enabling this for everyone else.

As I have mentioned earlier, the workflow functionality is very powerful, and even thought there are protections agains infinite recursions and such, there is still the risk that semi skilled powerusers creating workflows that put a heavy load on the asyncservice, so I would be a bit reluctant on letting them use this. Thorough training is a must before and try to teach them to keep the workflows simple. If you have several custom workflow activities, for instance, activities for integrating with other systems, I would be very careful since it is hard, if not impossible to restrict a custom workflow activity to just a selected amount of users.

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com

Internet Facing Deployment

by | Jun 1, 2009

As many of you know, one of the integral and unique parts of Dynamics CRM 4.0 is it’s ability to be Internet facing. This does not only mean that you have to choose between the ameneties of a normal AD logon and the grace of IFD, you can have both. So, even if you are just a small company with just a small business version of CRM 4.0 and not a larger corporation, there is no reason why you shouldn’t use Dynamics CRM 4.0 with the IFD technology.

So, how do you do it?

There are some good documents provided by Microsoft on how to do it(like this one: http://www.microsoft.com/downloads/thankyou.aspx?familyId=3861e56d-b5ed-4f7f-b2fd-5a53bc71dafc&displayLang=en) but there are some parts of it that are a bit tricky and depend on some of the infrastructure components you have, like DNS, and that might not be Microsoft, or even hosted. So I thought I’d describe a bit about how it works and give an example of how to do it.

First of all you have to do a normal installation of CRM 4.0. You can install on port 5555, 80 or any other TCP port. It doesn’t matter for IFD deployment, however, port 80 or 443 have to be made available from the Internet so the physical placement of the CRM server is critical. You can use normal redirect techniques or reverse proxy lookup (as in ISA-server). The important fact is that the server must be placed so that it can be reached from the outside.

The next thing you have to set up is an external name that you can use when adressing the server from Internet, hence it has to be a real name and not just an internal name. If you have registered a domainname you could set a hostname to point to the organizations you want to access.

I used dyndns.com and registered a name like “mydomain” and my CRM organization was mycrm, when using IFD that would make the address for this org:

http://mycrm.mydomain.dyndns.com

Make sure that everything bellow mydomain.dyndns.com also gets redirected to you CRM servers external URL (port 80 or 443 depending on if you are using SSL or not)

The next step is to run the IFD Tool as referenced in the Microsoft Document. It can be downloaded from here.

Use it to set up CRM by setting the right stuff in the web.config and setting some keys in the registry. It is a lot easier than doing it yourself. You have to set it up to the external name you have chosen.

Now the final step is to add a host header in the IIS website for CRM for *.mydomain.dyndns.com or explicitly for mycrm.mydomain.dyndns.com for port 80 or 443 depending on your setup.

Now you should be able to browse to mycompany.mydomain.dyndns.com and get to the logon screen.

To get reports working you have to install the report connector software found on the CRM CD/DVD.

There are of course lot of variations to this, using reverse proxy of ISA Server and all the options of setting up certificates for SSL but I’ll leave that out of this posting to keep it simple.

Menno has recently published a posting on this as well (http://www.tekoppele.com/Blog/post/2009/05/30/How-to-configure-an-Internet-Facing-Deployment-for-Microsoft-Dynamics-CRM-40.aspx, and there are several other blogs and MS KB articles concerning this. If you have problems, try taking it a step at a time and analyse and design the setup first so that you have got it figgured before you start configuring!

Good luck!

Gustaf Westerlund
Microsoft Dynamics CRM Architect

Logica
www.logica.com