Siebel workflows are quite powerful. They provide a good alternative to scripting, And that is a recommendation that you see from most of the designers, and from Oracle.

But, can workflows to everything that scripts can do? To a large extent they can - but remember, The celebration of workflows just to avoid scripting will become a purely academic exercise rather than building a scalable/performing application.

• Workflows to a good job of becoming a vehicle/container for other workflows and scripts
• Siebel operation steps provide a good way to update business component/fields in one go without additional configuration ( scripting)
• Runtime events make it really easy to trigger of workflows, and allow you to retain a certain degree of control without making any code changes
• Powerful out-of-the-box services (Including EAI Siebel Adapter, SIS OM PMT Service, PRM ANI Utility Service etc.) bring the best out of workflow. They provide really powerful functions and improved performance
• You can easily make the workflow wait for an application step or user interaction, and resume the workflow in the action completes. Long-running workflows take this a notch higher By providing an easy way to enable Workflows that have to execute over days/weeks
• Simple decision rules are easy to implement. You can mix and match with Data Validation Manager to enhance what a workflow can do
• Workflows are invaluable in integration. With just one click you can enable a workflow to become a web service, and expose the Siebel processes to the external world. The architecture of the workflow makes it really easy to receive data, process data with the help of OOB components, and provide response.
• Workflows are easier to debug. All it takes is a couple of values to be set in the live application, and workflows will start logging each one of the steps and argument values

Scripts, on the other hand, or derided much - although most of that fault has to rightfully lie with the developers. Scripting represents the absolute limit of what a customisation can do in your application.

You can only control most of the application actions/user actions through scripting, but also interface with third-party components, client components and even provide a Java container.

• Scripts provide an optimal way to perform business component operations. In complex validations/automation scenarios you can minimise database operations and improve the performance drastically.
• Scripts provide access to multiple failures of tricks, business components, custom methods, and business services - all without leaving the business service/method. This is easier to read than a cascading thread of workflows and sub workflows

Implement what is best for the Application. #

Over the years I have seen workflows being abused to create things that are confusing, difficult to maintain, and with no regards to application performance.

Workflows are made needlessly complex - probably because one of the designers is against scripting altogether, or the team wants to test the limits by accomplishing something only using workflows.

The other extreme is harder to find nowadays, but was more common 6-10 years back. Hotheaded programmers came to Siebel, they scripted, and then they left.

• Start and end everything for the customisation using scripting
• introduce everything that you need, and the kitchen sink in one business service
• Sprinkle business services, object scripts, configuration and workflows with profile attributes just to see the fun
• Use profile attributes instead of global variables just because you can. Use global variables rather than passing values to the functions just because you can.

If you have been a person who maintains that code, you know what exactly I am talking about.

I believe that your customisation has to be a smart combination of traditional configuration, workflows and scripting.

For example which one do you think looks better?

• A workflow with well marked, modularised scripts to perform actions.
  

  

• Everything written in one function in a single business service
• Everything represented as a workflow operation that is a big spaghetti mess
  

  

Best practices for workflow/scripting #

Keep these practices in mind when designing workflows/ scripts.

• Workflows are best used as a container. They can provide a good starting point that can be made flexible using runtime events.
• Workflows should be the points of entry/exit for interfaces
• Workflows must use script components to siphon off some of the complexity and improve performance. Avoid too many repeated Siebel operation steps and hard to trace decision steps
• Scripting must be used as reusable components. For example: if you are updating multiple components/fields using a business service, try to modularise code into - a function that manipulates data using property sets based on input parameters, and yet another function to perform updates. Functions should act like building blocks of scripting and must be usable regardless of where they are invoked from.

In summary: it is just common sense.