Office

What do the configuration files contain?

The configuration files contain information such as server login information, email management settings, Microsoft Office integration options, and as well as Microsoft Office application specific operations depending on the user settings/preferences. For example, file operations like Open, Save, Save as and so on for Microsoft Office applications like Word, PowerPoint, Excel, Visio, and MS Project. For more information about the Office and email configuration files, see:

• Customizing Microsoft Office applications

• Customizing the email templates

Groups

What is this feature?

Groups are lists of multiple users. They are a collection for assigning identical access privileges to certain documents, workspaces, or folders to the group members. For example, if a group has access to a document, the users in the group can access the document.

When does this feature help me?

This feature enables you to add users to a group and providing accessing to documents. Before providing group access to documents in a library, add the group to the list of registered groups in the library, and then add the relevant users to this group.

Where can I find this feature?

Navigate to the ACCESS > Groups.

Roles

When does this feature help me?

Roles enable you to organize privileges and functions selectively across your organization. For example, a role named Developers can be created and will have each of the privileges granted or denied to fit their function within the organization. All users assigned to the Developer role will have the same set of privileges.

Custom Fields

When does this feature help me?

You can use this feature when customer wants to map their set of metadata to the existing custom fields, and also add values to the custom fields so that they can use these values from iManage Work clients.

Can you list the custom fields exposed by iManage Control Center?

Custom1 through custom30. Additionally, custom1/custom2 and custom 29/custom30 each have parent-child relational table (subtables). That means, custom1 can have many aliases directly associated from custom2. For example, if custom1 is Client, and the client is Microsoft, then custom2 could be matters, such as litigation, mergers, acquisitions, Human resources, and Intellectual property cases.

Classes /Subclasses

What kind of document Classes/Subclasses am I allowed to create?

The document classes that you create depend on your company and your library requirements. Document classes can be categorized by genre, department, region, and so on.

What do this Classes/Subclasses contain?

These fields determine:

• Whether a copy of the document can be echoed to a user’s local hard drive. This is applicable only in DeskSite and FileSite.

• The custom fields of profile information that are required for the document.

File Handlers

What are these applications, where are they stored, and what type of information do they contain?

Each iManage library has a list of applications associated with it. It contains the information required to integrate document handling applications with iManage Work Server. This information includes the:

• Procedure to associate document types and applications

• Program to launch applications from iManage Work Server

When is the information mentioned in the preceding section provided?

When an iManage library created, it is initialized with a common list of applications.

Properties

Can the existing forms from Dialog Editor be migrated to iManage Control Center?

1. Existing forms are converted to the new format supported by REST.

2. All the REST calls use the new format.

3. Dialog Editor forms are used only by the iManage Work classic clients.

My environment is running in compatibility mode. What should I do to update the forms correctly?

If your application is running in compatibility mode, that is, iManage DeskSite plus iManage Work Office integration, whenever you have to update a form, you should update it in both the following:

• Dialog Editor tool for iManage DeskSite

• Form Editor in iManage Control Center for iManage Work.

What steps should I take after upgrading iManage Work Server?

After upgrading the iManage Work Server in an on-premises environment, you must save all the forms in Form Editor, even if they appear to have all the appropriate form fields. This ensures that forms are saved in the new format, so that the client applications can consume them. It also breaks the connection to the legacy Dialog Editor forms. If an organization is running in compatibility mode, it needs to use Dialog Editor for DeskSite/FileSite forms, and Form Editor for iMange Work forms.

Are all the forms that were used in iManage Work Classic Clients available in iManage Work?

In Dialog Editor, seven different forms were available for customization. However, Form Editor has only five forms to reduce the complexity.

Which of the forms are deprecated in Form Editor though they were used in Dialog Editor?

In the iManage Work client applications, additional forms were being used. However, with the new Form Editor, we have realigned all the dialogs and deprecated the following forms:

• new_version - The mobility application used this form when saving a new version of a document, whereas iManage Work Desktop for Windows was using edit_document. Now, iManage Work Mobility also uses edit_document form.

• new_workspace - iManage Control Center used this form in Ad Hoc Workspace dialog, whereas iManage Work Web was using edit_workspace. iManage Control Center now uses edit_workspace form.

• quick_search - This form in Dialog Editor was never used in any of the iManage Work clients.

How is the new Form Editor different than the legacy Dialog Editor?

• iManage Control Center was earlier using "new_workspace" form for the New Workspace command, whereas iManage Work Web and iManage Work Mobility were using "edit_workspace". In Form Editor, iManagControl Center will now use "edit_workspace" to align with the other apps.
  

• iManage Work Mobility was using "new_document" form when saving a new document, whereas iManage Work Desktop for Windows was using "edit_document". In Form Editor, iManage Work Mobility also uses "edit_document" to align with other iManage Work applications.

• iManage Work Mobility was using "new_version" form when saving a new version, whereas iManage Work Desktop for Windows was using "edit_document". In Form Editor, iManage Work Mobility also uses "edit_document" to align with other iManage Work applications.

Where is each form used in iManage Work client applications?

The following table represents the new forms available in Form Editor and the context in which they appear in various iManage Work clients. In this table, N/A means that the form is not used in this context.

General

How are tiers and features mapped?
Tiers are categorized based on administrator privileges and all iManage Control Center features are distributed among tiers.

See Roles for a list of all tiers and their capabilities.

Can I customize Tier 1 and Tier 2 capabilities so that they match my firm's support practices?
Tier 1 and Tier 2 capabilities are designed around best practices for help desk support and cannot be customized. However, iManage recognizes that there is no one-size-fits-all policy and this feature may be added to a future version of iManage Control Center.

Why are metadata descriptions hidden in iManage Control Center?
To maintain the security of iManage Work content.

Why are document names hidden in iManage Control Center?
To maintain document security.