Deploying Apps

My vendor provided me with an updated package of an application that I have already added. What is the best practice for adding the new package? Do I refresh the existing application, or do I create a new application?

Typically a vendor provides an updated package to fix a bug or misconfiguration. This is handled by the cloud administrator.

My vendor provided me with a package that represents a beta of their next version. I want to test this in my production environment with my colleagues, and I don't want to disrupt our regular user base. What is the best approach to this?

To get a new application or update an existing one, contact the iManage Cloud administrator.

We have completed testing a new version from our vendor and want to roll it out in production to all users. What is the best approach?

To get a new Application or update an existing one, contact the iManage Cloud administrator.

We plan to deploy a new application in a rolling deployment across offices. How do I handle this?
It's quite simple to make an application available to new users. When you are ready to introduce the application to new users, modify the security of application and include the new users. For simplicity, it's best to have groups defined by office and merely assign the application to each group rather than having to maintain a large list of users.

I have several applications that are deployed to subsets of users. When I refresh the package, will the users/groups who are authorized to use the application preserved?
When you refresh a package, the server reads configuration settings, such as OAuth settings, from the package and update as needed. Security is preserved.

We use a third-party vendor for back-end administration. What must we do to ensure that our admin tools continue to operate?

In general, third-party applications continue to operate without any additional changes. The only applications that need to be registered are those that use the new REST API v2. Applications that use the COM API are not required to be registered. Confirm with the vendor whether the application is using the COM API or the REST API v2 if you are unsure.

We are deploying a brand new iManage environment. Do we have to register iManage applications?
No, you do not have to register iManage applications. The server comes pre-registered with iManage applications. You can set security on the applications, if necessary.

Registering Apps

Must I register all iManage applications, such as ASCII Importer, Workspace Generator, etc.? How about all my third-party applications?

The only applications that need to be registered are those that use the new REST API v2. ASCII Importer, Workspace Generator, and so on, still use the COM API and are not required to be registered. iManage applications that use the REST API v2 are already registered for your convenience. Contact third-party application vendors to find out if their applications need to be registered.

When I review details of applications, I see "This application adds user interface extensions to <some other app>." What does this mean?
As described in the overview, applications can either customize the experience of another application, or they can be standalone. The Application properties is providing this information to make it easier to understand where the application is being used.

I have an application that adds a context menu to Work 10 Web. I have registered the application and secured it to the right group of people, but we still don't see it. What else do I need to do?
Context menus require an additional step to configure where the menu appears in relation to all other context menus. You must go to Client Setup > Web > Context Menus and add the menu.

Editing Apps

Why can't I edit certain fields after registering an application?

Certain fields, such as Client ID, Publisher, and Website, are set by the application developer and cannot be modified by an end user.

Can I change any info on any iManage applications?
You can change the description, and apply security to the iManage applications. None of the other properties are editable.

Why can't I change the name of an application?
The name of an application is used in the DOCHISTORY table to record the application that performed the action.

What's significant about application names in the DOCHISTORY table?
The benefit is that you can now pinpoint who is using specific applications, whether it's for adoption purposes or for troubleshooting purposes. For example, suppose you have a third-party comparison tool that has a context menu in Work 10. When the user invokes the context menu, the application will save a redline as a new version. With the new Applications framework, the audit entry reflects the comparison tool as the application that saved the version instead of the Work 10 application.

Deleting/Disabling Apps

What's the difference between deleting an application and disabling an application?
Deleting an application removes it from the system entirely. If you ever wanted to reinstate the application, you have to register the application again from the store. Disabling, on the other hand, leaves the application in the system, but prevents its use. Best practice is to leave applications in the system and disable them.

Does disabling an application remove any of the configuration, such as the OAuth details or the users who can access it?
No, disabling an application does not remove or change any of the configuration. In the future you can re-enable the application and it continues to operate as previously deployed.

Why can't I delete iManage applications? Why do I get an error when trying to delete an application?
You cannot delete iManage applications because they are part of the iManage platform. If you don't use an iManage application, you can disable it. You receive an error when trying to delete an application that has settings associated with it. You can disable the application instead.

We have many applications listed, but we don't use them. Can I delete these applications?
For iManage apps, the Delete option is not available. You can delete non-iManage applications that don't have settings associated with them. These are removed from the list of Applications. If you ever want to reinstate the application, you have to add it back from the store. iManage apps can be disabled. They continues to appear in the list of Applications, but they are not active in the system. If you ever want to reinstate the application, you have to enable it.

What happens for end users if I disable an application that extends an iManage app?
The UI immediately disappear. For example, if an application provides a context menu, the context menu is no longer available. For Web applications, this happens on a Web refresh.

Do I need to restart the server if I disable an application? What happens for users who are currently logged in and have access to the application?
You do not need to restart the server when disabling applications. If the application happens to be active for a user, that is, the user has the application open, any subsequent requests from the application causes an error for the user.