Activity rules provide us with one way to automate the processing of work in pega applications using a program-like approach.
A data transform rule provides a purpose-built rule for easily transforming and mapping clipboard data without using activities. In general, the data transform defines how target data (properties, pages, etc) is mapped from and transformed by source data (properties, pages, etc).
Activities are harder to maintain and not as easy to construct as other rules in PRPC.
We should not use an activity for calculations or property validations that we can implement as
constraints rules or Declare Expression rules. Use of a declarative rule (rather than an activity) eliminates the need to control how and when an activity executes. A best practice is to use declarative processing rather than activities when feasible.
For data manipulations, we can use a Data Transform instead of an activity.
To query from an external DB, we can use Report Definition rules instead of activities.
We may need to automate the processing of cases with a sequence of steps to be executed. Most of the time, this is possible with the steps in the case designer or multiple shapes in a flow rule or with
declarative rules or data transform rules or a combination of those and other rules.
Also remember that before writing our own activities, take a look at the standard activities that come with PRPC.
There are certain scenarios where we cannot avoid writing an activity. For example:
To perform Case related functions such as creating a case instance, routing the case, or updating
the work status, as part of certain operations such as parsing an input file.
To send requests to external systems or to receive requests from external systems.
To perform functions such as writing to a log file or to the history database.
While they share much helper code, e.g. for the generation of property sets and When conditionals, the two assemblers have very different implementations. This difference was primarily necessitated by Data Transform's "dual step page" model.
The approach has been to factor popular use cases for Activity into other, simpler rule types such as Data Transform. My understanding of this trend was that we didn't really want to replace Activity, because anything sufficiently complex to replace Activity will probably be just as confusing. I think this has been largely successful: use cases that previously demanded Activity, e.g. looping and branching to set values on a page, are now commonly performed in Data Transforms instead. Because it's unlikely that there will ever be a strong business need to simplify some of the more esoteric Activity methods, it's unlikely that Activity ever goes away entirely.
The general product direction is away from Activities unless absolutely necessary.