You are viewing limited content. For full access, please sign in.

Question

Question

The most multi of of multi-value fields. Is there a better way?

asked on April 3, 2024

Hi everyone,

I'm working on a project where a generic document is sent to multiple people but not everyone. The document is so generic, it doesn't even contain a custom salutation.

However, the metadata is different for each person it's sent to. My first thought was to create a documents with a multiple multi-value field  groups, containing potentially 4 to 1100 groups per document. 

UI clutter issues aside, how well does LF handle this kind of scenario? Is there a better solution? Given the low cost of storage, I could also just create the document 4 to 1100 times but would rather not. 

-Ben

0 0

Replies

replied on April 3, 2024

Hi Ben,

I think you're right to be concerned about the usability of a document with 1100 multi-value field groups. I don't have performance numbers on hand, but I think UI clutter can't really be set aside here: that's a lot of scrolling.

Are there are any more details you could provide about why you want to have different metadata for each person, or a concrete example? Is that 1100 number coming from "this is sent to 1100 different people" or "this is sent to 100 people, each of which need 10-12 fields"?

My rough guess would be that you could use forms and/or workflow to better facilitate this, perhaps by splitting the document when it gets to unwieldly, putting the document within the context of a form, and/or removing fields as they become irrelevant.

0 0
replied on April 3, 2024

Hi @Brianna,

(side question, why doesn't my "@" seem to work?)

Thanks for replying, here's some more information:

  • This one: "this is sent to 1100 different people"
  • A standard document is sent to multiple people. 
  • The documents doesn't relate to the person, rather a contact-point and a job. This means that each document on the system will have at least three user-defined attributes to make it unique. For argument's sake: Customer ID, Project ID, Business Area ID. Actually, I said there were 3 attributes for simplicity. In reality, there are more including Package ID (to track what documents were transmitted together).
  • When a customer-services person takes a call, they need to bring up all documents relating to those codes that the customer has received.
  • If a search returns your 10 documents, and one of them has 1100 multivalue groups, do you really need to scroll through the metadata to prove it? There is an argument to be made that search/retrieval is all that matters. 

 

The customer doesn't use forms. They will use a custom front-end, and occasionally LF Web Client. 

-Ben

0 0
replied on April 4, 2024

Ah thanks for elaborating -- the metadata is used almost entirely for searching. In that case, I agree, the metadata pane performance is not relevant.

I was hoping if you shared more details, there would be a viable alternative approach, but I admit I'm stumped if you need to return the same document when searched on any one of those 1100 values.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.