Forum Discussion
MattMakris
6 years agoQrew Assistant Captain
Hi @Don Larsonā,
You nailed the data architecture (1st diagram). The reason we designed it this way is so you can 'attach' multiple documents to another record, such as an activity, while having the ability to 'attach' existing documents that records in other tables are linked to, so that we don't have to re-upload duplicate documents. For instance, if an Opportunity is linked to a proposal document and a contract document, I'd also like to link a task to those same documents. This way we aren't loading our database up with duplicate files and we're able to link multiple documents to single records..
------------------------------
Matt Makris
------------------------------
You nailed the data architecture (1st diagram). The reason we designed it this way is so you can 'attach' multiple documents to another record, such as an activity, while having the ability to 'attach' existing documents that records in other tables are linked to, so that we don't have to re-upload duplicate documents. For instance, if an Opportunity is linked to a proposal document and a contract document, I'd also like to link a task to those same documents. This way we aren't loading our database up with duplicate files and we're able to link multiple documents to single records..
------------------------------
Matt Makris
------------------------------
DonLarson
6 years agoQrew Elite
Matt,
I got lucky on the diagram so now let me make sure I understand the work flow problem with this architecture.
Is the User issue adding a New Document and Document Selection OR
is the problem adding a Document to an existing Document Selection that is already related to the Activity?
------------------------------
Don Larson
Paasporter
Westlake OH
------------------------------
I got lucky on the diagram so now let me make sure I understand the work flow problem with this architecture.
Is the User issue adding a New Document and Document Selection OR
is the problem adding a Document to an existing Document Selection that is already related to the Activity?
------------------------------
Don Larson
Paasporter
Westlake OH
------------------------------
- MattMakris6 years agoQrew Assistant CaptainDon,
The problem is that there are too many steps to add a new document that is related to the Activity record. Currently the user has to load the new Document Selection form, then from the Related Document selector they select "+ Add new document". From there a new window opens and they have to fill out the "Add New Document" form ('Documents' table), then go back to the 'Add Document Selection' form, then back to the 'Activity' record they were adding or editing.
I am trying to figure out how allow them to either link to an existing document or add a new document. If a new document is requred, then I'd like them to only have to view/complete one form, rather than viewing several screens to do what would otherwise be a simple task.
Matt
------------------------------
Matt Makris
------------------------------- DonLarson6 years agoQrew EliteMatt,
Allow me to rename the middle table.
Now we can think of that table as the bundle of documents that need to be related to a variety of different parent tables.
The User has three different workflows that we have to support even though they just think of it as adding a document.
1) Create a new Document Package
2) Relate an existing Document Package to the Activity
3) Add Documents to a Document Package that is Related to the Activity
3) is the easiest. On the Activity form you can put an Embedded report that shows all the Document Packages that are related to the Activity. Make sure there is an Add Document button and the Package gets bigger by one document each time.
2) Getting this right requires more information about the other tables in the application and how you tied them together. If you have a Package related to an Opportunity that you now want to also relate to the Activity, you can have a report of all Packages not currently related to an Activity. A quick Grid Edit will then relate that package to the Activity and all the Documents in that package will be tied to the Activity. This will get tedious quickly as the number of Packages in your application grows.
Any chance there is a hierarchy of the other tables to take advantage of? Something like this:
Now the Users can search for Packages that all share the same Related Client going up the relationships.
On you Activity Form is going to be a different button for the User to Search for the package to relate. It will be a link to the correct report with the filters needed to make the Users life easy.
Use case one is the most complex because the User has to do everything. The complexity of your Document Package form and the number of required fields before you can add Documents to the Package really impact the workflow.
Lets assume you have no required fields in the Document Package.
Name the button on the Activities Form Create Document Package. This will help the User understand that they are not in situation 3)
Go to the Settings on the Document Package Table and click the check box for Save Parent Record
What this will do is take one click out of the process for the User. When the Users on the Document Package form the first time and they click Add Document, the Document Package will auto save.
------------------------------
Don Larson
Paasporter
Westlake OH
------------------------------