When hitting Back or closing a browser window, Appcoll will keep a page locked for editing. Currently there is an option for an administrator to go into a user's contact page and "clear all locks and filters." I'd like to request an easier and quicker solution: a "clear own locks" button that any user can press in the event that they accidentally navigate away from a page. This would also decouple "locks" and "filters," since this issue doesn't actually have anything to do with filters, and clearing filters is undesirable in these situations.

I'd like to request a new field in Appcoll, that returns a comma separated list of inventor first names.

Currently, the way we have to do it is like this:

Step 1 - template definition:
Hello {Matter.Inventor1.First}, {Matter.Inventor2.First}, {Matter.Inventor3.First}, {Matter.Inventor4.First}, {Matter.Inventor5.First},

Step 2 - form generation based on template (assume this matter has 3 inventors)
Hello John, Tim, Mike, , ,

Step 3 - manual editing
Hello John, Tim, and Mike,
[["and" inserted and extra commas removed]]

My proposal would eliminate step 3.

Proposed step 1 - template definition:
Hello {Matter.InventorFirstNames},

Proposed Step 2 - form generation based on template:
Hello John, Tim, and Mike,
[["and" inserted and extra fields removed by AppColl backend logic]]

A similar proposal is possible for other lists of variable length, such as inventor full names and email addresses. This would eliminate a lot of manual editing on our end and further reduce likelihood of errors.

@jonah-soundhound-com bump, +1 for this request please

Appcoll allows for some field formatting options, as shown here: https://support.appcoll.com/form-emails-and-letters/formatting-text-fields-in-form-letters-and-emails

I'd like to suggest an additional formatting code, such as (AddPeriodToInitials), which adds a period to any letter that appears alone.

Example:
{Matter.Examiner} = John A Smith
{Matter.Examiner(AddPeriodToInitials)} = John A. Smith

This would solve one of the manual corrections we need to perform.

This will help greatly with form letters such as interview agendas, in which we address the examiner by their name. For example, assume that we have an Examiner named Joe Smith. The Examiner's information is imported from PAIR as "Joe SMITH." If I write a form letter in which I address the examiner, I would write it as:

Hello Examiner {Matter.Examiner},

which would populate as:

Hello Examiner Joe SMITH,

I would then need to manually remove the Examiner's first name, and re-type or otherwise reformat the last name to get what I really want, which is:

Hello Examiner Smith,

Appcoll already has some level of intelligence when importing contacts, such as when importing an Excel file with plain names. Appcoll does create/identify contact records, and populates first/middle/last names accordingly. Appcoll should do this with Examiner names as well.

The ideal user experience would be:

Hello Examiner {Matter.Examiner.Last},

which would give the desired result.

This also provides the benefit of allowing us to maintain examiner contact information, such as emails and phone numbers, which makes our lives easier and reduces time spent finding this information from other sources.

Columns in the UI are formatted such that there is a maximum quantity of characters in a column and, regardless of window size or column width, no additional characters are displayed. The following shows the same columns, with different window sizes:

^ Here, no ellipses are shown even though the column is cut off by the window.

^ Here, the column width happens to line up correctly with the ellipses, and it looks as it should.

^ Here, the window size is larger and the column is therefore wider. However, the ellipses don't change, and column now simply has blank whitespace where there could be letters.

^ There is no good reason for this to happen - dynamic columns are a problem that has been completely solved for many years in web page design.

@ChristianS9906 I agree. For example, just got this today:

"review e-office action" and "review uspto communication" for the same item. No need for this.

It would be nice if we could more quickly/readily access the form letters we most commonly use, while removing or de-emphasizing form letters we use less or not at all.

Appcoll allows for some field formatting options, as shown here: https://support.appcoll.com/form-emails-and-letters/formatting-text-fields-in-form-letters-and-emails

I'd like to suggest an additional formatting code, such as (LastWord), which returns the last word in a field.

Example:
Hello Examiner {Matter.Examiner}, = Hello Examiner John A Smith,
Hello Examiner {Matter.Examiner(LastWord)}, = Hello Examiner Smith,

This would solve one of the manual corrections we need to perform.

@BrandonK6644 I have made this request before as well. This is better than having Appcoll's internal matter codes (sequential matter number for your account) as a client-facing email address. The simplest way to implement it would probably be to add a mapping between what they already have, and the email address we desire. This could be done on a per-matter basis, and would need a code/differentiator between different accounts. Example implementation:

Friendly intake email address prefix for BrandonK's account: BK
Friendly intake email address prefix for SadiqA's account: SA
*Each account administrator may specify their own prefix via admin dashboard, so long as it is unique from all other account prefixes.

BrandonK's matter:
Attorney Ref: FOO123
Appcoll Matter ID: BrandonK001
Appcoll default intake email address (current implementation): BrandonK001@intake.appcoll.com
Friendly intake email address (default): BKFOO123@intake.appcoll.com
Friendly intake email address (customizable via Matters module UI; prefix is not changeable): BKpatent123@intake.appcoll.com

SadiqA's matter:
Attorney Ref: FOO123
Appcoll Matter ID: SadiqA001
Appcoll default intake email address: SadiqA001@intake.appcoll.com
Friendly intake email address (default): SAFOO123@intake.appcoll.com
Friendly intake email address (example customized address): SAmatter456@intake.appcoll.com

Emails to BKFOO123@intake.appcoll.com and BrandonK001@intake.appcoll.com are routed to BrandonK's "FOO123" matter

Emails to SAFOO123@intake.appcoll.com and SadiqA001@intake.appcoll.com are routed to SadiqA's "FOO123" matter

^ The client doesn't need to see the arbitrary Appcoll matter ID in the email fields; firm/account code is used to route emails to the correct account and matter, even if attorney docket number itself is ambiguous

@joe_appcoll Nice, thanks

Any movement on this suggestion? This would remove a recurring source of frustration if implemented.

@BrandonK6644 What is the difference in your suggestion vs. having client-specific transient tasks that themselves trigger billing items?

@ChristianS9906 I agree. For example, just got this today:

"review e-office action" and "review uspto communication" for the same item. No need for this.

@RichardS3059 Do you have form letters attached to automatically generated tasks that are triggered when an eOfficeAction is received?

@gregg_appcoll All first actions/notices of allowances on my account have this issue.

Automatically generated forms, which are triggered by USPTO eOffice Actions, may use out-of-date information in certain circumstances, such as first Office Actions.

In the initial stages after an application's initial filing, the USPTO has placeholder information is in the USPTO system such as "Docket Central" as the examiner and "OPAP" as the art unit. This information gets updated by the USPTO prior to the first Office Action being sent out.

As one (basic) example, I have an Office Action Response template that is generated when an Office Action is received. This template populates basic bibliographic information, such as title, inventor, examiner, art unit, etc. In the current implementation, Appcoll does not update the information in the Appcoll system before automatically generating documents; it uses whatever was in the system before. Appcoll updates its internal information after generating documents based on an eOfficeAction. On second and subsequent actions (with no examiner or AU change), this works fine. However, on first actions, it results in situations like Appcoll-generated form fields getting populated with the placeholder information such as "Docket Central" and "OPAP."

@GeorgeJ4336 For what it's worth, I have only ever used Appcoll email intake as a CC, and I would imagine this is the intended use

@scott_appcoll Is there any concern with ambiguity here? If I have a first matter with MATTER ID 1234 and I have a second matter with MATTER ID 4321 and ATTORNEYREF m1234, wouldn't they both get resolved by [AccountIntakeID]m1234@intake.appcoll.com?

@scott_appcoll Nice, I think this works. Can we get an option to choose the new format in appcoll-generated notification emails as well?