Action Handlers

Action handlers may be assigned to an event on the Reconcile Process or to a post type (under the Post Process). The table below describes each event handler and its parameter. The table also lists the events to which the action handler may be assigned.

TIP: General Purpose Action Handlers are assigned differently. If you want to set up the Compress Geodatabase or Run Orphaned Versions Cleanup Tool Action Handlers, see the General Purpose Action Handlers section after the table below for additional details.

Ensure the correct service is selected in the Available Services window.
Select the Version Processing tab. Action handlers may be assigned to an event on the Reconcile Process or under Post Process to an event for a post type.
Right-click an event under the Reconcile Process or a post type under Post Process and then select Add Action Handler.
Select the newly created action handler to display the field properties in the right side of the window.
- Action Name: Provide a name for the action handler.
- Action Handler: Select an action handler from the drop-down list. The table below describes each action handler. Only the action handlers available for the selected event are listed in the Action Handler field.
- Action Handler Description: Once you select an action handler, the action handler description appears in this field. This field is read-only.
- Parameters: This list all available parameters for the action handler. The table below describes the parameters for each action handler.

Click Apply to save changes and continue displaying the Geodatabase Manager window. Click OK to save changes and close the window. Click Close to close the window. You are prompted to save changes before closing.

IMPORTANT: You can modify the configuration of a service while it is running but your changes are only active until the service is restarted.

You can assign an existing action handler (along with its parameters) to multiple events. To do this, right-click the existing action handler and click Copy. Right-click an event and select Paste. Action handlers can be assigned (and pasted) only to valid events (see Can Assign To column in the table below).

To remove an action handler, right-click it and select Delete Action Handler.

Action Handlers

Action Handler	Description	Parameters	Can Assign To	Node Type
Call Node Deleter	Deletes the Process Framework node (such as session or design) associated with the version being posted. In some cases, locks may persist on the version temporarily preventing it from being deleted (such as after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. The action handler marks these Process Framework versions for deletion by the Orphaned Versions Cleanup Tool. Do not assign Call Node Deleter and Call Work Request Node Deleter to the same event.	None	After Post	Session or Design
Call Work Request Node Deleter	Deletes the work request associated with the version being posted and all designs under the work request. In some cases, locks may persist on the version temporarily preventing it from being deleted (such as after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. The action handler marks these Process Framework versions for deletion by the Orphaned Versions Cleanup Tool. Do not assign Call Node Deleter and Call Work Request Node Deleter to the same event.	None	After Post	Design
Cleanup Feeder Sync	Deletes the information from the MM_EDITED_FEATURES table after posting during Feeder Sync. This requires Feeder Manager Sync to be enabled through the Feeder Manager Configuration window.	None	After Post	Session, Plain, or Design
Compress Geodatabase	Geodatabase compression removes unnecessary states and rows from the system tables where versions and versioned edits are tracked TIP: This is a General Purpose Action Handler and is set up on the Schedule Tab. It does not run during version processing.	None	Not Applicable	Not Applicable, this action handler runs on the entire database.
Delete GDB Resources	Deletes any stored data from the ArcFM System Tables associated with the version being posted. This may include Targets tab data, stored displays, page templates, design map extent, and design data.	None	After Post	Session or Design
Delete Non Postable Features	Deletes any features or objects in the processed version corresponding to the model names configured in the Parameters section. For example, use this action handler to delete any features that should not be posted (such as Work Locations) from a version prior to posting it. IMPORTANT: Before deleting a non postable feature, verify the following: 1) WorkRequest polygon feature class does not use the MMDONOTPOST model name or the model name that you specified in the Model Name parameter and 2) the value UseDesignID is set to TRUE. If these values are not correct, the WorkRequest class does not use the DESIGNID field, and the action handler deletes all of the features in the WorkRequest feature class.	UseDesignID: Indicates whether the field with the DESIGNID model name assigned should be used to identify any features to be deleted. If set to True, then only features with the specified model name (ModelName parameter) and a DESIGNID model name matching the current design will be deleted. This parameter applies only to Designs. Default=True. ModelName: Specifies the class model name(s) used to identify objects and features to be deleted. Default=MMDONOTPOST.	Before Post	Session or Design
Delete Objects By Work Function	Deletes any features or objects in the version that are present in the corresponding design and have the specified WorkFunction values. For example, use this action handler to delete any features that have a work function value other than Install.	WorkFunction: Specifies the Work Function value to be deleted. Any feature or object in a design that has a work function that corresponds with this parameter will be deleted. Default=2, 4, 8, 16, 32.	Before Post	Design
Delete Version	Deletes the version being processed from the database. In some cases, locks may persist on the version temporarily preventing the version from being deleted (such as after running QA/QC). If the version contains child versions, it may not be deleted until the children have been removed. The Delete Version action handler logs the version into the Delete Version Queue table. The service attempts to delete any version in this queue at the beginning of each process cycle.	None	After Post	Any
Delete Work Request Polygon	Deletes the work request polygon associated with the current version.	None	After Post: When the work request polygons are in the version to which you are posting to. Before Post: When the work request polygons are not in the version to which you are posting to.	Design
Email Reconcile/Post Error	Sends an email via SMTP in response to an error encountered in the reconcile or post events.	MailServer The name of the SMTP mail server. Recipient: A comma-delimited list of recipient email addresses. From: The email address of the sender. Reply-To: The reply email address. FilterErrors: This setting defaults to False, which means an email is sent out for all errors encountered. A setting of True filters out specific errors before sending an email. With a value of True in this parameter, an email is NOT sent out in the event of the following errors: VERSION_NOT_AVAILABLE, VERSION_BEING_RECONCILED, VERSION_BEING_EDITED. Users can set up owner-targeted email notifications in the parameter list.	ReconcileError PostError	Any
Fiber Circuit After Reconcile	Resolves the conflict in circuits that affect F_CIRCUIT and F_CIRCUITCOMPONENT table (e.g. duplicate records in ELEMENTGUID field of F_CIRCUITCOMPONENT table).	None	After Reconcile	Any
Fiber Circuit Before Reconcile	Checks for conflict in circuits that affect F_CIRCUIT and F_CIRCUITCOMPONENT table (e.g. duplicate records in ELEMENTGUID field of F_CIRCUITCOMPONENT table).	None	Before Reconcile	Any
Log to Post History	Writes or updates a row in the Post History table with the name of the version being processed, the start and end times of the post operation, and the status of the operation. For example, configure this action handler on the Before Post event to write a row into the Post History table. Configure it again on the After Post event to update the row with the end time and status of the post operation. This information is visible on the Monitor tab.	None	Before Post After Post	Plain
Log to Reconcile History	Writes or updates a row in the Reconcile History table with the name of the version being processed and the start and end times of the reconcile operation, and the status of the operation. For example, configure this action handler on the Before Reconcile event to write a row into the Reconcile History table. Configure it again on the After Reconcile event to update the row with the end time and status of the reconcile operation. This information is visible on the Monitor tab.	None	Before Reconcile After Reconcile	Any
Log Session/Design to Post History	Inserts or updates a row in the Post History table and includes Process Framework information, if available. This information is visible on the Monitor tab.	None	Before Post After Post	Session or Design
Orphaned Versions Cleanup Tool	Removes orphaned versions left behind in the database when a session or design is deleted. TIP: This is a General Purpose Action Handler and is set up on the Schedule Tab. It does not run during version processing.	None	None	Session or Design
Reset Designer Fields	Updates fields on features and objects in the version according to the parameter settings. While the primary intent is to update Designer-specific fields, additional fields may be configured as well. You may add parameters to reset other fields or remove default parameters to prevent field values from being reset.	WorkFlowStatus: Type the value used to reset this field. Default=0 WorkFunction: Type the value used to reset this field. Default=0 WorkRequestID: Type the value used to reset this field. Default=Null DesignID: Type the value used to reset this field. Default=Null WorkLocationID:Type the value used to reset this field. Default=Null	Before Post	Design
Run Feeder Sync	This updates the Feeder Manager 1.0 fields (FeederID, FeederID2, and FeederInfo (without island or terminal device bits set)) in the geodatabase for the features that exist in the MM_EDITED_FEATURES table. This requires Feeder Manger Sync to be enabled through the Feeder Manager Configuration window. NOTE: The ParentCircuitSourceID information is not updated in the geodatabase with this action handler.	None	Before Post	Any
Run QA	Executes any QA validation rules configured for any features or objects that have been inserted or updated in the version being processed. When configured on the Data Validation event for post types, this action handler will enable the Validation Error event if any QA validation errors are detected. All QA validation errors will be written to the log file specified in the QALogFile parameter.	StopPost: Indicates whether the post operation should continue if QA validation errors are detected. Set the value to True to halt the post process. Set it to False to continue the process. Default=True. QALogFile: Define the location of the log file. This log file contains only QA errors. Geodatabase Manager does not currently support saving log files across a network. The path in this field must be local.	Data Validation	Any
Send Notification Email	Sends an email via SMTP. This action handler is more generic than the Email Reconcile/Post Error action handler. This action handler allows you to define the subject and body using parameters. It may be used to send an email at any point in the process.	MailServer The name of the SMTP mail server. Recipient: A comma-delimited list of recipient email addresses. Subject: Text to be included in the email's subject line. Body: Text to be included in the email's body. From: The email address of the sender. Reply-To: The reply email address. Users can set up owner-targeted email notifications in the parameter list.	Any event (except Reconcile and Post events)	Any
Transition Node	Useful for post type events related to session or design node types only. Transitions the Process Framework node related to the process version to a new state. This transition is made directly to the database rather than through the Process Framework API. Consequently, this action handler may be useful in environments where Process Framework caching behavior may not be turned off. If Process Framework caching is disabled, it is recommended to use a Process Framework task to transition the state of a node, rather than an action handler.	FromState: The original state of the session or design associated with the version being processed. The Value attribute must match the state in the Process Framework database and is case-sensitive. No value is required in the Type field. ToState: The new state of the session or design associated with the version being processed. The Value attribute must match the state in the Process Framework database and is case-sensitive. No value is required in the Type field.	Post Error After Post In Conflict Validation Error Reconcile Error	Session or Design

General Purpose Action Handlers

There are two General Purpose Action Handlers; Compress Geodatabase and Run Orphaned Versions Cleanup Tool.

General Purpose Action Handlers are different from typical Action Handlers in that they are not scheduled on the Version Processing tab. Instead, they are scheduled on the Schedule tab.

The General Purpose Action Handlers don’t run during version processing.

For additional instructions how to set up General Purpose Action Handlers, see the Compress Geodatabase and Orphaned Versions Cleanup Tool topics.