Scripting VS Workflows

Before I start with the post I want to say. I know Scripting is not good for upgrades, performance and I try to avoid it as much as I can. But a recent requirement that I worked upon has got me thinking and I don’t seem to have an answer.

The Requirement:

Create a button on a List Applet. On Click of that button the Status of SR should get changed to ‘Close SR’.


As we all know there are several ways to this requirement. If button was not involved then a Simple On Field Update Set n user property would have sufficed. In this case we need to invoke a custom method that should set the field value. That leaves us with two approaches

Approach 1:

Create a Named Method n user property. Invoke a workflow and set the status to ‘Close SR’. The workflow and user property will look something like this.

Named Method 10 :
"CloseSR", "INVOKESVC", "Service Request", "Workflow Process Manager", "RunProcess", "'ProcessName'", "Close Service Request", "'RowId'", "[Id]"


This approach gives us a Scriptless Solution.

Approach 2:

In the Service Request BC BusComp_PreInvokeMethod do the following

if(MethodName == “CloseSR”)
this.SetFieldValue("Status","Close SR");
this.SetFieldValue("Desired Status","Closed");
return (CancelOperation);

I know scripting is bad and scripting on Objects is even worse but we can clearly see that Approach 1 involves calling a business service (Workflow Process Manager) to invoke workflow and Approach 2 is just doing a SetFieldValue.  I think the effort in Approach 1 is higher as well as the overhead involved to complete the task. So, what should we do in this case.

I understand the point that it starts like this and over a period of time it becomes a mess but if I start following the Approach 1 for all the similar requirement I believe the situation will get worse.  I am not really sure what is the best thing to do here so I am putting this here in the open for everybody to give there opinion and find the best possible answer.

I am listening………


Suggestion by Sudha worked great. I was able to achieve the solution by creating two Named Method n user properties to set the values for two fields.

Thanks Sudha and everyone for discussing and hopefully this will help others to avoid scripting in similar situations.

13 Responses to Scripting VS Workflows

  1. You can use the following User Property:

    Named Method 10:
    “CloseSR”, “SET”, “Status”, “Close SR”

    There is no need to invoke the workflow to set the Status field.

  2. Hi Neel,

    thanks for this post. I use to tell my students that they should avoid anything that an Oracle Siebel engineer wouldn’t do.

    This includes object-side scripting (at the BC level in this case).

    The Siebel Repository is full of examples how requirements like the above are handled and most of the time, the Named Method N user property is used.

    There are hundreds of preconfigured business services and workflows which are the result of implementing complex requirements over the past 10 years in Siebel standard applications.

    So why shouldn’t a custom developer use user properties, business services and workflows instead of cluttering the repository with the same code all over again.

    Maybe even more important:

    Ensure that you have a consistent business process oriented approach to identify requirements and design your solution with performance and upgradeability in mind.

    have a nice day


  3. Please be aware that ‘Named Method’ user property does not work on “CSSBuscomp” class in Siebel 7.7. I have not tested this in Siebel ver 8.

    Ref : Siebel Developer’s Reference > User Properties > Named Method n, this user property is designed for use with Class ‘CSSBCBase’.

  4. My Opinion is Calling the WF using the Named Method User Property is the best approach

    Thanks and Regards
    Venkatesh Rajkumar

  5. There is one more thing to be in mind. The Solution with escript or the User Property is done in the memory with the Context of the user session. The solution with the workflow creates a different context in the background. This means you need another database query to create it. If you want to see the new value in The UI you need another requery in the database.

    So the User Property or escript is the better approach especially if you compare it with normally recommended way to use workflow and personalization.

    If you think a step further to go live and deployment. It’s easy to Change the srf. For the workflow solution you need to change srf, repository, personalization, and workflow. Don’t forget to activate them. That’s a lot of points to fail.

    Be in mind. As simple as possible

  6. I liked the approach suggested by Sudha but as mentioned tht it works on some classes of applet, it would be better to include those 2 lines of script here.

  7. 2) Configure a static picklist , which is present in two views should show different values.

    EX : account status picklist present in account applet in two diff views “account view” and “account admin view”. In account view picklist should show the values open,active where as in account admin view it should show the values expired,cross border

  8. Simple tasks require simple solutions.

    For something as simple as assigning a field value, creating a WF seems a little bit over the edge. Scripting is not always ideal, but for simple tasks that involve a simple change withing a single object … it is quite practical.

    Of course in this case, definitly the user property set would be a better choise. But lets take under consideration what ADO said about the WF solutions creating new query instance and that means hevier and slower perfomance.

    But nevertheless, Scripting is and will always be a simple aswer for a simple requirement. Let’s keep that in mind.

    • I agree to the above approach.. but the problem starts when everybody starts building on top of that for other requirements … then it becomes a mess.

      I guess.. this struggle will go on for ever and we will always have to this balancing act… of choosing between scripting and scriptless solutions

  9. I like the post and especially the comments. Scripting vs. Workflows: it has been debated in many forums for many years now. But the right question to ask is: Which approach is more efficient (for the developer/for the overall project solution/for the management)? Factors affecting efficiency could be anywhere from developer’s skills and knowledge to project timeline to the server resources consumed… The list could go on depending on individual scenarios. But form my experience and from an architect’s point of view, I would, in all circumstances, recommend the use of “Named Methods”. And yes, Siebel Product Engineers do work with a lot of so called “Named Methods” in the DLLs! 🙂

Leave a Reply