mirror of
https://github.com/langgenius/dify-docs.git
synced 2026-07-21 20:05:22 -04:00
edits to main doc
This commit is contained in:
@@ -27,12 +27,22 @@ You can have a maximum of 10 parallel branches from one node, and up to 3 levels
|
||||
|
||||
## Variable access
|
||||
|
||||
In serial flows, nodes can access variables from any previous node in the chain.
|
||||
In serial flows, nodes can access variables from any previous node in the chain.
|
||||
|
||||
In parallel flows, nodes can access variables from nodes that ran before the parallel split, but they cannot access variables from other parallel nodes since they're running simultaneously.
|
||||
In parallel flows, nodes can access variables from nodes that ran before the parallel split, but they cannot access variables from other parallel nodes since they're running simultaneously.
|
||||
|
||||
After parallel branches finish, downstream nodes can access variables from all the parallel outputs.
|
||||
|
||||
## Answer node streaming
|
||||
|
||||
Answer nodes handle parallel outputs differently. When an Answer node references variables from multiple parallel branches, it streams content progressively:
|
||||
|
||||
- Content streams up to the first unresolved variable
|
||||
- Once that variable's node completes, streaming continues to the next unresolved variable
|
||||
- The order of variables in the Answer node determines the streaming sequence, not the node execution order
|
||||
|
||||
For example, in a flow where `Node A -> Node B -> Answer` with the Answer containing `{{B}}` then `{{A}}`, the Answer will wait for Node B before streaming any content, even if Node A completes first.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -5,6 +5,14 @@ icon: "keyboard"
|
||||
|
||||
Speed up your workflow building with keyboard shortcuts.
|
||||
|
||||
<Callout type="tip">
|
||||
**Global Search**: Press `Cmd+K` (macOS) or `Ctrl+K` (Windows) anywhere in Dify to search everything—apps, plugins, knowledge bases, even workflow nodes. Use slash commands like `/theme` to change appearance, `/language` to switch languages, or `/help` to access documentation.
|
||||
|
||||

|
||||
</Callout>
|
||||
|
||||
|
||||
|
||||
## Node operations
|
||||
With any selected node(s) on canvas:
|
||||
|
||||
|
||||
@@ -70,18 +70,6 @@ Identify common user question types that would benefit from annotation coverage.
|
||||
**Match Quality**
|
||||
Review similarity scores to ensure annotations are triggering for appropriate questions without false matches.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Start Small:** Begin with your most frequently asked questions or critical information that must be accurate.
|
||||
|
||||
**Test Thresholds:** Experiment with similarity thresholds to balance match accuracy with coverage.
|
||||
|
||||
**Monitor Misses:** Track questions that should have hit annotations but didn't, indicating needed threshold adjustments or annotation gaps.
|
||||
|
||||
**Update Regularly:** Annotations become stale over time. Review and update them based on changing policies or user feedback.
|
||||
|
||||
Annotations work best as a complement to AI generation, handling the known cases while allowing AI to handle novel questions.
|
||||
|
||||
---
|
||||
|
||||
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/guides/annotation/annotation-reply.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)
|
||||
|
||||
@@ -38,17 +38,21 @@ Answer nodes support rich content delivery including text, images, and files in
|
||||
<img src="https://assets-docs.dify.ai/2025/04/5a70a5e568dded3975e54cfa84085c93.png" alt="Answer node chat interface" />
|
||||
</Frame>
|
||||
|
||||
## Streaming Behavior
|
||||
|
||||
Answer nodes stream content progressively based on variable availability. The node outputs all content up to the first unresolved variable, then waits for that variable to resolve before continuing.
|
||||
|
||||
**Variable Order Matters** - The sequence of variables in your Answer node determines streaming behavior, not the execution order of upstream nodes.
|
||||
|
||||
For example, with nodes executing as `Node A -> Node B -> Answer`:
|
||||
- If the Answer contains `{{A}}` then `{{B}}`, it streams A's content immediately when available, then waits for B
|
||||
- If the Answer contains `{{B}}` then `{{A}}`, it waits for B to complete before streaming any content
|
||||
|
||||
This streaming behavior enables responsive user experiences while maintaining content coherence.
|
||||
|
||||
## Multiple Answer Nodes
|
||||
|
||||
You can place multiple Answer nodes throughout your chatflow to deliver content at different stages of processing. This enables:
|
||||
|
||||
**Progressive Responses** - Provide immediate acknowledgment while processing continues in the background
|
||||
|
||||
**Conditional Responses** - Send different content based on workflow branching logic
|
||||
|
||||
**Streaming Updates** - Deliver partial results as they become available during long-running processes
|
||||
|
||||
Each Answer node contributes to the conversation independently, allowing for sophisticated response patterns and user experience design.
|
||||
You can place multiple Answer nodes throughout your chatflow to deliver content at different stages of processing.
|
||||
|
||||
## Variable Integration
|
||||
|
||||
|
||||
@@ -125,16 +125,6 @@ docker-compose -f docker-compose.middleware.yaml up -d
|
||||
|
||||
The sandbox service requires Docker and isolates code execution from your main system for security.
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Data Parsing** - Extract specific values from complex JSON structures returned by APIs or other nodes.
|
||||
|
||||
**Mathematical Operations** - Perform calculations, statistical analysis, or data aggregation that preset nodes can't handle.
|
||||
|
||||
**Data Transformation** - Convert data formats, combine multiple data sources, or restructure information for downstream processing.
|
||||
|
||||
**Conditional Logic** - Implement complex decision-making logic that goes beyond simple if-else conditions.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -75,16 +75,6 @@ Here's a complete document Q&A workflow using the Document Extractor:
|
||||
<img src="https://assets-docs.dify.ai/dify-enterprise-mintlify/en/guides/workflow/node/d05301438e8aab7393bb5863554f1009.png" alt="Chat with PDF interface" />
|
||||
</Frame>
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Document Q&A Applications** - Build ChatPDF-style apps where users upload documents and ask questions about their content.
|
||||
|
||||
**Content Analysis** - Process contracts, reports, or research papers to extract key information and insights.
|
||||
|
||||
**Batch Document Processing** - Extract text from multiple documents simultaneously for analysis, indexing, or migration.
|
||||
|
||||
**Document Conversion** - Convert various document formats to plain text for further processing or storage.
|
||||
|
||||
## Processing Considerations
|
||||
|
||||
The Document Extractor uses specialized parsing libraries optimized for different file formats. It preserves text structure and formatting where possible, making extracted content more useful for LLM processing.
|
||||
|
||||
@@ -54,16 +54,6 @@ If your workflow has multiple possible execution paths (through If-Else nodes, f
|
||||
<img src="https://assets-docs.dify.ai/dify-enterprise-mintlify/en/guides/workflow/node/a103792790447c1725c1da1176334cae.png" alt="End Node - Long Story Generation Example" />
|
||||
</Frame>
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Consistent Output Structure** - Use similar variable names and data types across different End nodes in the same workflow for predictable API responses.
|
||||
|
||||
**Include Status Information** - Consider outputting success indicators or processing metadata alongside main results.
|
||||
|
||||
**Handle All Paths** - Ensure every possible execution path in your workflow leads to an End node to prevent incomplete executions.
|
||||
|
||||
**Document Output Schema** - Clearly document what each End node returns for API consumers and integration purposes.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -127,16 +127,6 @@ SSL certificate verification is configurable per node (`ssl_verify` parameter).
|
||||
<img src="https://assets-docs.dify.ai/dify-enterprise-mintlify/en/guides/workflow/node/090975269f8998f906c5636dde8d9540.png" alt="Customer Feedback Classification workflow" />
|
||||
</Frame>
|
||||
|
||||
## Common Integration Patterns
|
||||
|
||||
**API Data Fetching** - Retrieve user profiles, product information, or external data to enrich your workflow processing.
|
||||
|
||||
**Webhook Delivery** - Send notifications, status updates, or processed results to external systems and services.
|
||||
|
||||
**File Processing** - Upload documents for analysis, download resources for further processing, or integrate with cloud storage services.
|
||||
|
||||
**Multi-step API Workflows** - Chain multiple API calls together, using responses from one request to configure subsequent requests.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -60,18 +60,6 @@ Reference any variable from previous workflow nodes in your conditions. Variable
|
||||
|
||||
Use the variable selector to choose from available variables, or type variable names directly using the `{{variable_name}}` syntax.
|
||||
|
||||
## Common Patterns
|
||||
|
||||
**Content Routing** - Direct different types of content to specialized processing nodes based on categories, languages, or complexity.
|
||||
|
||||
**User Role Management** - Implement different workflow behaviors based on user permissions, subscription levels, or account types.
|
||||
|
||||
**Error Handling** - Check response status codes, data validity, or processing results to route workflows appropriately.
|
||||
|
||||
**Dynamic Processing** - Adjust workflow behavior based on input characteristics, processing results, or external conditions.
|
||||
|
||||
**Multi-path Workflows** - Create sophisticated branching logic that handles various scenarios and edge cases in your application.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -141,26 +141,6 @@ Iteration nodes output arrays that often need conversion for final use:
|
||||
</Tab>
|
||||
</Tabs>
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Token Limit Management** - Break large texts into chunks for translation, summarization, or analysis when content exceeds LLM context windows.
|
||||
|
||||
**Batch Processing** - Apply the same operations to multiple items efficiently, such as processing multiple documents or API calls.
|
||||
|
||||
**Quality Control** - Process items individually to maintain quality and handle errors gracefully rather than risking entire batch failures.
|
||||
|
||||
**Progressive Output** - Stream results as they complete instead of waiting for all processing to finish.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Choose Appropriate Mode** - Use sequential for ordered processing or streaming, parallel for independent operations requiring speed.
|
||||
|
||||
**Handle Errors Gracefully** - Configure error handling based on whether partial failures should stop processing or be skipped.
|
||||
|
||||
**Optimize Internal Workflows** - Keep iteration sub-workflows efficient since they run multiple times.
|
||||
|
||||
**Monitor Resource Usage** - Large arrays with complex processing can consume significant resources, especially in parallel mode.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -99,28 +99,6 @@ Handle workflows where users upload both documents and images:
|
||||
|
||||
This pattern automatically routes different file types to appropriate processors, creating seamless multi-modal user experiences.
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**File Type Routing** - Separate mixed uploads into specialized processing pipelines based on content type.
|
||||
|
||||
**Data Filtering** - Extract relevant subsets from large datasets based on specific criteria.
|
||||
|
||||
**Content Prioritization** - Sort and select the most important or recent items from collections.
|
||||
|
||||
**Quality Control** - Filter out invalid, oversized, or unsupported content before processing.
|
||||
|
||||
**Batch Preparation** - Organize data into manageable chunks for downstream iteration or parallel processing.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Plan Filter Criteria** - Define clear filtering rules based on your downstream processing requirements.
|
||||
|
||||
**Use Appropriate Output Types** - Choose between full arrays, first record, or last record based on how downstream nodes will use the data.
|
||||
|
||||
**Handle Empty Results** - Consider what happens when filters return no matches and plan appropriate fallback logic.
|
||||
|
||||
**Test with Real Data** - Verify filtering behavior with actual user uploads to ensure reliable operation in production.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -91,7 +91,8 @@ Force models to return specific data formats like JSON for programmatic use. Con
|
||||
|
||||
## Memory and File Processing
|
||||
|
||||
Enable **Memory** to maintain context across multiple LLM calls within a workflow run. The node includes previous interactions in subsequent prompts. Memory is node-specific and doesn't persist between workflow runs.
|
||||

|
||||
Enable Memory to maintain context across multiple LLM calls within a chatflow conversation. When enabled, previous interactions will be included in subsequent prompts as formatted user - assistant outputs. You can customize what goes into the user prompts by editing the `USER` template. Memory is node-specific and doesn't persist between different conversations.
|
||||
|
||||
For **File Processing**, add file variables to prompts for multimodal models. GPT-4V handles images, Claude processes PDFs directly, while other models might need preprocessing.
|
||||
|
||||
|
||||
@@ -96,26 +96,6 @@ Current verse: {{verse}}
|
||||
Refine and improve this poem based on your previous work.
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Content Refinement** - Progressively improve text, code, or designs through multiple LLM reviews until quality standards are met.
|
||||
|
||||
**Problem Solving** - Break complex problems into iterative steps where each cycle tackles the next logical piece based on previous progress.
|
||||
|
||||
**Research Workflows** - Iteratively search, analyze, and refine research queries based on findings from each search cycle.
|
||||
|
||||
**Quality Assurance** - Repeatedly test and validate outputs, making improvements until all criteria are satisfied.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Define Clear Exit Conditions** - Ensure loops have specific, measurable conditions for termination to prevent infinite execution.
|
||||
|
||||
**Set Reasonable Limits** - Use appropriate maximum iteration counts based on expected complexity and processing requirements.
|
||||
|
||||
**Manage State Effectively** - Use loop variables to maintain necessary information across iterations while avoiding unnecessary data accumulation.
|
||||
|
||||
**Monitor Progress** - Include logging or progress indicators to track loop execution, especially for long-running processes.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -61,25 +61,6 @@ The node provides both extracted parameters and built-in status variables:
|
||||
<img src="https://assets-docs.dify.ai/dify-enterprise-mintlify/en/guides/workflow/node/71d8e48d842342668f92e6dd84fc03c1.png" alt="Data format conversion workflow" />
|
||||
</Frame>
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Tool Parameter Preparation** extracts specific parameters from natural language for workflow tools that require structured input.
|
||||
|
||||
**Data Format Conversion** transforms text into formats required by other nodes, such as converting lists to arrays for iteration processing.
|
||||
|
||||
**API Request Preparation** structures data for HTTP requests to external services, handling the conversion from user intent to API-compatible parameters.
|
||||
|
||||
**Form Data Processing** extracts structured information from free-form user input for database storage or further processing.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Clear Parameter Descriptions** help the LLM understand exactly what information to extract and in what format.
|
||||
|
||||
**Provide Examples** in your instructions to improve extraction accuracy, especially for complex or domain-specific parameters.
|
||||
|
||||
**Use Appropriate Data Types** to ensure extracted parameters match the requirements of downstream nodes.
|
||||
|
||||
**Handle Extraction Failures** by checking the `__is_success` variable and providing fallback logic when extraction fails.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
|
||||
@@ -50,36 +50,6 @@ Each classification result routes to different knowledge bases and response stra
|
||||
|
||||
Add detailed classification guidelines in the **Instructions** field to handle edge cases, ambiguous scenarios, or specific business rules. This helps the LLM understand nuanced distinctions between categories.
|
||||
|
||||
### Memory Integration
|
||||
|
||||
Enable **Memory** to include conversation history when classifying input. This improves accuracy in multi-turn conversations where current input depends on previous context.
|
||||
|
||||
**Memory Window** controls how much conversation history to include, balancing context awareness with token efficiency and processing speed.
|
||||
|
||||
## Output Usage
|
||||
|
||||
The classifier outputs a `class_name` variable containing the matched category label. Use this variable in downstream nodes for:
|
||||
|
||||
**Conditional Routing** - Connect different workflow paths based on classification results
|
||||
|
||||
**Knowledge Base Selection** - Route to specialized knowledge bases for each category
|
||||
|
||||
**Response Customization** - Apply different response templates or processing logic
|
||||
|
||||
**Analytics and Logging** - Track distribution of user inquiries across categories
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Clear Category Boundaries** - Define distinct, non-overlapping categories with specific descriptions to improve classification accuracy.
|
||||
|
||||
**Appropriate Model Selection** - Choose models based on classification complexity. Simple binary classifications work with faster models, while nuanced multi-category classification may require more capable models.
|
||||
|
||||
**Test Edge Cases** - Verify classification behavior with ambiguous inputs that could fit multiple categories.
|
||||
|
||||
**Use Conversation Context** - Enable memory for conversational applications where classification depends on previous interactions.
|
||||
|
||||
**Monitor and Iterate** - Review classification results and refine category descriptions based on real usage patterns.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -74,14 +74,6 @@ Document files should be routed to a Document Extractor node to extract text con
|
||||
|
||||
You can mark any input variable as "hidden" to exclude it from the user interface while still making it available in your workflow.
|
||||
|
||||
## Configuration Best Practices
|
||||
|
||||
When designing your Start node inputs, consider what information is essential at the beginning versus what can be derived or collected later in the workflow. Requiring too many inputs upfront creates friction for users, while too few might limit your workflow's capabilities.
|
||||
|
||||
Choose descriptive variable names that clearly indicate what data they contain. Variable names should use underscores or camelCase consistently and avoid special characters that might cause parsing issues. Remember that variable names are case-sensitive, so `userName` and `username` are different variables.
|
||||
|
||||
For file uploads, consider setting appropriate file type restrictions and size limits. This prevents processing errors downstream and ensures your workflow receives the expected input formats.
|
||||
|
||||
## What's Next
|
||||
|
||||
After configuring your Start node, you'll typically connect it to nodes that process the collected input. Common patterns include sending user input to an LLM node for processing, using Knowledge Retrieval to find relevant information based on the input, or routing to different workflow branches with conditional logic based on input values.
|
||||
|
||||
@@ -106,28 +106,6 @@ When users submit forms, responses become structured JSON data available for imm
|
||||
|
||||
Template output is limited to **80,000 characters** (configurable via `TEMPLATE_TRANSFORM_MAX_LENGTH`). This prevents memory issues and ensures reasonable processing times for large template outputs.
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Report Generation** - Combine data from multiple sources into formatted reports with consistent structure and styling.
|
||||
|
||||
**API Response Formatting** - Transform internal data structures into user-friendly formats for external consumption.
|
||||
|
||||
**LLM Prompt Preparation** - Structure complex data into well-formatted prompts that improve LLM processing accuracy.
|
||||
|
||||
**Email and Notification Templates** - Generate personalized messages with dynamic content based on user data and workflow results.
|
||||
|
||||
**Data Transformation** - Convert between different data formats and structures for integration with external systems.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Use Descriptive Variable Names** to make templates readable and maintainable, especially when processing complex data structures.
|
||||
|
||||
**Handle Missing Data** with default values and conditional checks to prevent template rendering errors.
|
||||
|
||||
**Format for Readability** by using appropriate spacing, line breaks, and formatting to create clean, professional output.
|
||||
|
||||
**Test with Sample Data** to ensure templates handle edge cases and produce expected results across different input scenarios.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -66,26 +66,6 @@ Advanced workflows (v0.6.10+) can aggregate multiple groups of variables simulta
|
||||
|
||||
This is useful when branches produce multiple related outputs that need to be combined separately - for example, aggregating both text summaries and numeric scores from different processing paths.
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
**Multi-Category Processing** - Different content types require specialized processing but produce similar outputs that feed into common downstream logic.
|
||||
|
||||
**Conditional Data Sources** - Different conditions trigger different knowledge retrievals or API calls, but all results need the same final processing.
|
||||
|
||||
**Branch Result Consolidation** - Complex branching logic produces various outputs that ultimately need unified handling.
|
||||
|
||||
**Error Handling** - Main processing and fallback branches produce different but compatible results that downstream nodes can process consistently.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Plan Data Types** - Ensure all branches produce compatible data types before connecting to the Variable Aggregator.
|
||||
|
||||
**Consistent Output Structure** - When aggregating objects or arrays, maintain consistent structure across all branches for predictable downstream processing.
|
||||
|
||||
**Use Descriptive Names** - Name aggregated variables clearly to indicate they contain results from multiple possible sources.
|
||||
|
||||
**Test All Branches** - Verify that each possible execution path produces valid outputs that work correctly when aggregated.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -110,18 +110,6 @@ Build guided workflows that track completion status across multiple conversation
|
||||
|
||||
Use array conversation variables to track completed items. The Variable Assigner updates the checklist each turn, while the LLM references it to guide users through remaining tasks.
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Choose Appropriate Data Types** - Use arrays for growing collections, objects for structured data, and simple types for single values.
|
||||
|
||||
**Use Descriptive Variable Names** - Name conversation variables clearly to indicate their purpose and contents.
|
||||
|
||||
**Handle Data Growth** - Monitor array and object sizes to prevent excessive memory usage in long conversations.
|
||||
|
||||
**Initialize Variables** - Set initial values for conversation variables to prevent undefined behavior.
|
||||
|
||||
**Clear When Appropriate** - Use clear operations to reset variables when starting new processes or sessions.
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -142,23 +142,6 @@ When you enable "More like this" in your workflow settings, users can generate v
|
||||
"More like this" works especially well for creative workflows like content generation, where users want to explore different approaches to the same topic.
|
||||
</Tip>
|
||||
|
||||
## Best Practices
|
||||
|
||||
**For Single Execution Apps:**
|
||||
- Design clear input forms that guide users to provide useful information
|
||||
- Include helpful descriptions for complex parameters
|
||||
- Test the user flow to ensure results meet expectations
|
||||
|
||||
**For Batch Processing Apps:**
|
||||
- Provide clear CSV template examples with sample data
|
||||
- Include validation for common input errors
|
||||
- Consider processing limits for very large batches
|
||||
|
||||
**For Result Management:**
|
||||
- Enable saving for workflows that produce valuable outputs users want to keep
|
||||
- Use "More like this" for creative or exploratory workflows
|
||||
- Consider result export options for users who need external access
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -156,25 +156,6 @@ Before deleting apps, understand the impact:
|
||||
App deletion is permanent and cannot be undone. All associated data, logs, and user access will be lost immediately.
|
||||
</Warning>
|
||||
|
||||
## Best Practices
|
||||
|
||||
**Naming Conventions:**
|
||||
- Use descriptive names that explain the app's purpose
|
||||
- Include version numbers or status indicators when relevant
|
||||
- Consider team-wide naming standards for consistency
|
||||
|
||||
**Organization Tips:**
|
||||
- Regular cleanup of test and unused apps
|
||||
- Use consistent icons and descriptions for similar app types
|
||||
- Document major configuration changes
|
||||
- Keep production apps separate from experimental ones
|
||||
|
||||
**Collaboration:**
|
||||
- Share DSL files with team members for knowledge transfer
|
||||
- Use duplication to create team templates
|
||||
- Export important configurations before major changes
|
||||
- Consider access permissions when sharing apps
|
||||
|
||||
{/*
|
||||
Contributing Section
|
||||
DO NOT edit this section!
|
||||
|
||||
@@ -77,14 +77,6 @@ Community Edition requires email service configuration before invitations work p
|
||||
|
||||
**Configuration Access:** Model providers and plugins configured at the workspace level become available to all applications created by team members with appropriate permissions.
|
||||
|
||||
## Security Considerations
|
||||
|
||||
**Principle of Least Privilege:** Start with minimal permissions and upgrade roles based on demonstrated need and trust.
|
||||
|
||||
**Regular Access Reviews:** Periodically review team member roles and remove members who no longer need workspace access.
|
||||
|
||||
**Sensitive Configurations:** Only trusted team members should have Admin or Owner roles since they control model provider API keys and billing.
|
||||
|
||||
---
|
||||
|
||||
[Edit this page](https://github.com/langgenius/dify-docs/edit/main/en/guides/management/team-members-management.mdx) | [Report an issue](https://github.com/langgenius/dify-docs/issues/new?template=docs.yml)
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 1.7 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 113 KiB |
Reference in New Issue
Block a user