Visual Client side workflow ala Contact Processes

[#1]

Whatever you want to call them, Contact Processes need to be revived - they actually work now, but are not supported on the web.

This needs to be modernized so that they work for both, and improve the flexibility.

One area is third party processes - where one person's action causes the process to do something affecting another user needs to be more flexible, to include some standard scenarios, like scheduling a ToDo for the AccountManager of a Contact.

Another is to give it "awareness" of itself. Things like CurrentProcessId and other fields in the Process record like (UserDefined) CAMPAIGNID, OPPORTUNITYID,etc.

Contact processes is rapidly becoming one of the tools you can use to keep people from defecting from SalesLogix because it makes the system "respond" to actions that are being tracked. Right now, it depends on having vbscript modules thrown in to make it all work - it needs to be fixed.

Lead processs? - absolutely!  Get a new lead, have a process against it and when it is ready for conversion, have the workflow not only automated, but something the internal admin can build and maintain. 

Opportunity Process? - on closed-won have it push a To Do to somebody internal that needs to know the project is official and they can start planning.

There is no shortage of uses for this as long as it is something the customer can build and maintain in house at the sales admin / power user level.

I mean seriously - how many sales admins would IT trust with a copy of Visual Studio and/or give access to the server?

[#2]

Great post Walt!

I wonder how may SalesLogix customers (or BP's) have ever taken a close look at Contact Process and realized the great potential it has.

As some of us know, Contact Process has been around in SalesLogix since the beginning 13+ years ago. It had a graphical (designer) interface on day 0. With the v6.0 release of SalesLogix support for VBScript and the new forms (ActiveX) was added.

One area that has been perceived as a weakness of Contact Process is that it's a "client side" operation. Basically this is true. However, there is a way to "fake" Server side execution. It turns out this capability has also been there since day 0 (for 13+ years). It is called the "process user". the way this works is very simple:

    a - Load a copy of SalesLogix on a desktop (or server)

    b - Log into that copy as:

              user: process

              password: admin's password

Like Admin, this user is built-in and like admin it does NOT take up a SalesLogix license! You will see a dialog that pops up and tells you:

              You have logged in as the process manager.

              As the process manager you can scan processes for users.

              To use other SalesLogix features login as a different user.

So the result is the "process user" actually acts as a "proxy" for other (users) . You have now "faked" "server side" execution.

One of the really slick things in CP is that a CP can "call" another CP. So you can build up a library of reusable CP's and just link them together like Lego blocks. 

As Walt has pointed out, there are some things that do need to be enhanced in Contact Process. However, the design, development, implementation, testing, deployment, and maintenance of CP's does NOT require a VS C# programmer. This is a tool that was developed with the Business Analyst in mind (non-programmer). Want to get your hands on this and try it out? There are some samples in the SalesLogix Eval/Demo database that is on every SalesLogix distribution (or just get a copy of eval db from your BP. Once you have it (using 7.5.2 in this example):

    A - Simply open the SalesLogix (Windows) Architect

    B -  Manage Plugins (type contact Processes)

    C - Open one of the 4 sample provided

You will also find the Architecture help has a lot of info on CP's as well. 

[#3]

I agree. It's a pretty naive business strategy to ask customers to move to an architecture that doesn't have this. And it as silly not to enhance this over the years. CRM is about process at many levels, and it's something is often designed by end user groups. So, it makes sense that these power users will want to get their hands dirty, and not with C#.

Are you looking for successful customer outcomes or getting a cheap thrill because we now have a .NET architecture? I'm looking for SCO's

[#4]

Someone at the "old" SalesLogix organization (pre Best/Sage) that the whole CP thing actually had several patents granted.

[#5]

We are currently working on designs for this and expect to see the first set of features in an upcoming release. While we are not trying to replicate the graphical interface of the legacy contact processes, we want to allow users to accommodate the same objectives. We are targeting general admin users to configure these processes. The examples in the request are helpful and we encourage anyone interested to keep posting additional ones. Thanks

[#6]

Scott, What we would like is an updated Contact Process (made entity agnostic) - not a revamped PO that requires VS.

[#7]

PO isn't what the "IDEA" was talking about. So, you didn't really accept the idea. PO was an internal idea.

[#8]

I am glad to hear that this idea was "accepted" - I just wish I knew what that meant.

Assuming that you are doing something that is 1. Visual, and 2. Client side - there are a few more pieces here that need to be addressed.

1. It needs to work with Windows (LAN) Client interchangably with the Web Client. (Even better if you could include mobile in this). We need to address the automation needs regardless of access method. This is not an insurmountable obstacle - you just need to have processing instructions. i.e. Mixed environments could have tabs - if executing in windows client, if executing on web, if executing on mobile, etc. At this point we are tilting back towards developers, but given the right building blocks, a sales admin could handle it.

2. In addition to being Admin friendly - it HAS to have an API, and provide enough information back to the developer community that we can create reusable building blocks to address specific customer needs and to compensate for Sage design limitations.(Don't be offended here... they are a fact of life). Just give us the safety valve.

 Any advanced details that Sage can provide would be great - after all - having accepted the idea does not guarantee that you will get it right - and after all isn't that what you have this community for - to help make sure that you do get it right?

ws

[#9]

Good points Walter.

Having an API that we can use in both Windows and Web (maybe mobile ;-) is a top priority. 

[#10]

I want Workflow processes.  Example Management Approval, a sales exec has created a quote and needs his managers approval, this should be able to be launched from the existing Opportunity Process.   Workflow Processes should be able to be created from any place, Account, Contact, Opportunity, Ticket.    Workflow is all about replacing paperwork, its about making users life simpler.