Search

InterAction® Administrator Answer Center

Allowing InterAction Users to Edit the Data

  • Updated

Regardless of what you selected for the allow editing option, if the logged in user is IAADMIN or the Folder Administrator, he or she can edit the data.

InterAction provides two ways to control changes to the data brought in with Application Collaboration:

  • Most data sets can be configured with an Allow Editing in InterAction option. This lets users edit the data in the Windows Client. This primarily applies to Windows Client users; Web Client always ignores the allow editing option for all data sets other than the related contact data set.
  • You can configure the Data Change Management rule set for the data source. When users make changes to the data in the Web Client, those changes are funneled through the Data Change Management process.

These options are covered in the following sections:

Using the Allow Edit Option for a Data Set

For company and person data sets, the option is called Allow users to edit all name fields in InterAction.

If the Allow Editing in InterAction option is selected for a data set, end users with appropriate access rights can edit the data brought into InterAction using that data set. For the most part, this only applies in the Windows Client, since changes in the Web Client are managed by the Data Change Management process (see Application Collaboration and Data Change Management).

Note that changes made in InterAction are only stored in InterAction; the changes are not also transferred to the external system.

If the Allow Editing in InterAction is not selected for a data set, all the data brought into InterAction using that data set is locked down in InterAction. Users with access rights that would normally allow them to edit this data now cannot edit the data. In this case, the external system essentially owns the data and is the definitive source for all changes. Again, this primarily applies in the Windows Client.

The Allow Editing in InterAction option is available for the following data sets:

  • Company
  • Person
  • Address
  • Additional Field (both single and multiple-value)
  • Related Contact (since this data is not managed by Data Change Management, the option controls what users can and cannot do in the Web Client as well as Windows Client)
  • Notes (as with related contacts, this option does apply in the Web Client as well as the Windows Client)
  • Module (Matter, Engagement, or Opportunity - see your applicable Related Module user guide)

The allow editing option does not apply to the following data sets:

  • Activity
  • Classification
  • Group member
  • Folder Link

This is because the data added by these data sets is never locked down by Application Collaboration. Users with appropriate access rights can always edit activities, classifications, and folder membership regardless of whether the data was populated using Application Collaboration.

You set the Allow Editing in InterAction option independently for each data set you create. For example, you might allow edits for additional fields but not addresses. Since you can use different data sets of the same type, you can be very granular. For example, you could set up two separate additional field data sets - one to populate fields that should be editable and one to populate fields that should be locked down.

When using Application Collaboration for a one-time data conversion, allow editing for all the data sets. This is because InterAction is used for all future updates to the data. Standard InterAction security can protect the data as needed. 

When using Application Collaboration for ongoing integration with an external system, such as a time and billing or accounting system, you normally set up your harvesting and transforming to take place on a regular basis. For instance, you might set it up to harvest new and changed billing information once a week, then transform the data into InterAction. This keeps the data fresh.

If a user edits information from the external system, these edits are lost the next time Application Collaboration transforms the data. For this reason, you normally do not want to allow editing for ongoing integration. For suggestions of when you would use this option, see When Would I Use the Allow Edit Option?

Application Collaboration and Data Change Management

The Data Change Management process in InterAction defines rules that determine how changes made to contacts in the Web Client are handled. For example, a rule might state that all new addresses added to the contact are reviewed after the fact by the data stewards, while another rule might require that company name changes be submitted to the data stewards for approval before the update can take place at all.

Each Application Collaboration data source has a corresponding rule set. The rule set is applied to the data coming from that data source. If users change the data in the Web Client, those changes are managed according to the Data Change Management rules. This lets professionals contribute their changes (which might be better than what is in the external system) while at the same time your organization can maintain the data in the separate external system.

When you create a new data source in Application Collaboration, InterAction automatically creates this corresponding rule set. The rule set uses the default external system rule collection, which requires all changes to the external system data to be submitted to the data steward for approval, while new data added to the contacts (such as new addresses) is allowed but sent to the data steward for review.

By default, the rule set for a data source uses the Data Administrators group as the owner. You can change this if necessary when configuring the rule set in InterAction Administrator.

You can configure the rule set for a data source if you want to change the behavior. You configure rule sets in InterAction Administrator. 

If you configure a rule set for a data source, the Data Change Management rules for that rule set apply to data brought in using the following data sets:

The Data Change Management rules have no affect on data brought in from the additional field, related contact, notes, classification, activity, or folder link data sets.

Example of Using Data Change Management and Application Collaboration Together

The external system rule sets are designed to make it possible for Web Client users to send requests to update the data that comes from external systems. For example, suppose you are using Application Collaboration to bring client data in from your accounting or time and billing system. You create a data source called Accounting System for this, and you configure data sets to create the contacts and update additional fields with financial information. You also bring in several addresses and phone numbers for the clients.

In this scenario, you want your accounting system to be the main source of the data. All changes to the data should be made in that system, since the data in that system is harvested and refreshed in InterAction on a regular basis. However, what happens if a professional end user learns that a client is moving to a new address? That address change should be made in the accounting system, not just in InterAction.

To accomplish this, you would need the Data Change Management rule set for your accounting system data source to be configured as follows:

  • The rule set uses the default Externally Owned rule collection (although this could be adjusted if necessary). This rule collection requires that any new data for the contacts be reviewed, and any changes to the data from the external system be submitted for approval.
  • The owner for the rule set would be the data steward who is responsible for making updates to data in the accounting system.

Now if a Web Client user changes the address that came from the accounting system, the change triggers a submission change management ticket. The data steward responsible for reviewing these tickets sees the requested change in his or her Data Change Management Inbox. That individual can then apply that change to the client in the accounting system. The next time the data is harvested, InterAction is refreshed with the new data.

When Would I Use the Allow Edit Option?

The option to allow editing for a data set is useful when using Application Collaboration for a one-time conversion. In this case, the data comes from the other system just once; all further updates are done in InterAction. For this type of conversion, allow editing for all data sets in the data source.

The option can also be useful when using Application Collaboration for ongoing updates, although you do need to be more careful since end user edits can potentially be overwritten. For example, assume you are bringing clients and their financial information into InterAction using Application Collaboration. The company names used in the accounting system are the full legal names for the companies. Although the names are correct from a billing perspective, they are not useful for marketing use in InterAction. Since the names are used in mailings, searches, and reports in InterAction, your organization wants to clean up these names in InterAction.

In this case, you would select the Allow Editing option for the company data set used to create the clients. In addition, you would clear the applicable fields on the Data Rules tab for the data set. This prevents Application Collaboration from overwriting these fields.

After bringing in the data from the other system, users can edit the company names as needed in InterAction.

But What About Data Change Management?

As described in Application Collaboration and Data Change Management, users in the Web Client can always edit the data from the external system, regardless of the settings for the data set. Their changes can be routed through the change management process. Normally, this is intended to get changes back to the original external system - for example, a user changes an address in the Web Client. That change is sent to the data steward responsible for the accounting system, who then updates the accounting system.

If you are allowing changes to the external system data directly in InterAction (such as the company name example above), then the only difference is that the data steward can make the change in the InterAction Windows Client instead of the external system. For example, if a Web Client user changes the company name TELENORTH FINANCIAL SERVICES INCORPORATED to simply TeleNorth Financial Services, the data steward can update the company with the correct name right in InterAction.

You can also adjust the rules to allow these types of changes to be accepted or to only require review rather than submission. You do this by changing the rules for the external system rule set.