Please find the answers for the below questions

What is process Model?

A process model is the primary tool in Appian for describing a workflow. Developers graphically lay out the workflow, which may assign user tasks, manipulate data, post system events, or update other design objects. Process models are frequently used with record types to provide users with tools to act on the information shown by the record.

In single sentence its a executable workflow with different activities involved.

docs.appian.com/.../Process_Modeling_Tutorial.html

Different type of gateway in apian? and what are its uses?

1. XOR — Exclusive Decision/Merge (Exclusive OR)
   This type of Gateway node allows one incoming path to continue, while excluding any others. It executes a single outgoing path determined by the conditions you set.
2. OR — Inclusive Decision/Merge
   This type of Gateway directs incoming flows to one of many possible output paths, based on the condition(s) you set.
3. COMPLEX — Complex Decision/Merge
   This type of Gateway allows you to selectively accept (or restrict) incoming paths and evaluate rules to determine outgoing paths. For example, you can restrict the node to accept only the first 3 out of 4 incoming paths, or require input from certain nodes before continuing. Outgoing paths can be configured in the same manner as other Gateway nodes.
4. AND — Parallel Fork/Join
   This type of Gateway directs all incoming workflow(s) to all of the possible branches. If more than one incoming path is used, all incoming paths must reach the node before the process can continue. It can also be used to join all incoming paths into a single workflow.

docs.appian.com/.../Gateways.html

Process model best Practices?

There are various best practices for process modeling with respect to process model and process nodes. It also depends on the activity we are using like messaging. Following are a few basic best practices.

Process Models
Process model has labeled swim-lanes with default assignment
Process model display name is set and is dynamic (e.g. “Started by pp!initiator”)
All process flows have been tested and no errors occurred
All models have custom Alert settings configured using groups
Processes that contain user input tasks or a significant portion of log: Archive after 3 days. Everything else: Delete after 0 days.
Process models are split into sub-processes to compartmentalize sets of functionality and large cumbersome process models are avoided
Models contain no more than 30 nodes
Models contain no more than 50 process variables
XOR gateways are used in front of MNI nodes to check for empty/null values
Process flow will always reach at least one terminating end event
Process-to-process messages are targeted to a specific process instance using PID
All complex logic is documented using annotations (anything that isn't obvious)
All external integrations are contained in their own subprocesses to minimize the impacts of the external systems changing their interfaces. E.g. anything other than query rules and data stores should be encapsulated.
If the external integration points are using CDTs to exchange data (such as integration with web services), use these CDTs locally within the integration process models or rules and create business CDTs to be used by the rest of the application. This prevents changes in external systems data structures from having widespread impacts in the application.
Best practices for creating memory efficient models have been followed
Design short-lived processes to perform actions and maintain the data. Consider using process model based related actions instead of quick task related actions when possible.
Ensure there is no way to unintentionally loop through a smart service node (db write, create document, etc)

Process Nodes
Nodes are named with verb-noun format
Task display name is set and dynamic
Every SAIL form node has all inputs specified as process variables or activity class parameters
All XOR/OR gateways have a single incoming flow
All outgoing flows from a gateway are labeled
XOR gateways are used instead of OR
Node inputs do not make the same query call more than once
CDTs are not passed by reference between parent and sub-process
Looping functions are used instead of Multiple Node Instances where possible
On the Other Tab for Forms, check the "Delete previous instances" and do not check “Keep a record of the form”
Use rules and constants instead of hard-coded values in the process nodes

Different between loads with evaluated?

load(): Lets you define local variables within an expression for an interface and evaluate the expression with the new variables, then re-evaluate the function with the local variables' values from the previous evaluation.

with(): Lets you define local variables within a function and evaluate the expression with the new variables. Note: In interfaces, this function differs from the load() function because it recalculates the local variable values after interactions. This recalculation always happens, even if the interaction's updates could not have impacted the variable's value. This means data queries and other slow operations in with() variables can have important performance impacts.

Have a look at the new evaluation function, a!localVariables(). It does everything load() does but with additional refresh options that may drastically simplify your design.

what is CDT?

Its one of the data objects.

As opposed to a primitive or system data type, a custom data type (CDT) is a developer-defined data structure. Data Types allow designers to create a logical grouping of related data that can then be used by other objects to share data. Data can be shared internally, for instance between an interface and process model, or a web service that uses a CDT.

Because a data type will always be used in context of another object, it does not have individual security settings.

Tq bro for your early response

Tq bro for your early response