I have a document generation use case in Appian where I maintain a Request table and a separate Letter table that supports multiple versions of documents per request. For each letter version, I store selected template components such as header and footer (single selection) and multiple paragraphs, which are mapped through a separate association table to maintain order. These templates are stored in reference tables and contain placeholders in the format [placeholderName], which can appear anywhere within the text. In the first task, users select the required header, footer, paragraphs, and optional sections like privacy policy or guarantee content, and those selections are saved against the letter record. In the second task, based on the selected template content, I combine all the text and for each placeholder I need to fetch values from different data sources (for example, customer name from a customer table, address from another table, sender details from a user table, etc.), present those values in dropdowns for user selection, and use the selected values to populate a preview as well as generate the final document. Additionally, the system must support multilingual functionality where both predefined template content and generated documents should be available in different languages (currently French and Spanish), based on user choice, while maintaining the same placeholder structure across languages.
I am confused by how to extract and map the placeholder with values from correct source tables and find and replace them in the document. Can anyone help? I'm thinking maintaining separate table or add a one more column in the reference table for placeholder if the sentences contains palce holder that can be added in separate column. But still finding the place holder and replaceing it will actually values for user to update and replaceing it in documents I need some idea or help
Discussion posts and replies are publicly visible
Please check the following approach. I am not 100% sure I understand the problem.
Your current challenge lies in the decoupling of template content from data logic. Instead of trying to store placeholder mappings within the reference tables or adding specific columns for every sentence, you should implement a Centralized Placeholder Registry.
This approach bridges the gap between your text blocks and your data sources through four clear steps:
Dynamic Extraction: Once a user selects the header, footer, and paragraphs, use a Regex expression (via a shared component or plug-in) to scan the combined text. This identifies all unique tags (e.g., [cust_name], [addr_city]) currently present in the draft.
[cust_name]
[addr_city]
The Registry Table: Create a reference table that maps each unique tag to a Source Type. For example, [cust_name]is mapped to "Customer Entity," while [sender_dept] is mapped to a specific "Constant." This acts as your "source of truth" for what each bracketed term actually means.
[sender_dept]
Dynamic UI Task: In your second task, use the list of extracted tags to filter your Registry. You can then build a dynamic interface where dropdowns are generated only for the tags found in the document. The data for these dropdowns is fetched based on the source defined in the Registry.
Language-Agnostic Substitution: Since the placeholder tags (e.g., [date]) remain identical regardless of whether the surrounding text is French or Spanish, you only need one replacement logic. Use the substitute() function or a Document Generation Smart Service to swap the tags for the user's selected values just before the preview or final generation.
[date]
substitute()
By using this "Dictionary" approach, you avoid the mess of maintaining placeholder columns in every content table and ensure your multilingual support stays clean and scalable.