Parent Types Explained

Understanding Parent Types in Flows

When creating a Flows Process in Membrain, one of the key configuration steps is selecting a Parent Type. This setting determines what kind of entity the Flow is tied to - and helps ensure the workflow is properly connected within your CRM environment.

There are four Parent Types to choose from:

1. Company - Perfect for processes at an account level like project and delivery planning
2. Contact - Useful for individual-focused processes, like recruitment, training deliveries, and other external contact workflows
3. User - Great for internal organization, including staff onboarding, personal routines, and other user-specific workflows
4. None - Best for team-wide initiatives that don’t belong to a specific entity, such as marketing coordination, event planning, or shared templates

Choosing the Right Parent Type

Selecting the right Parent Type ensures your Flow connects to the right data and fits naturally into your workflow.

Each Parent Type determines what the Flow is centered around, whether that’s a company, contact, user, or no specific entity. This affects where the Flow appears in Membrain and who is expected to work within it.

When deciding which Parent Type to use, focus on ownership and intent. Ask yourself who the process belongs to and who needs visibility into it. A company-level process is typically shared across a team, while a contact or user Flow is more focused and specific.

Data Availability and Reporting in Flows

The selected Parent Type determines what fields are available throughout a Flow Project.

Each Flow Project always has access to its process fields, along with fields associated with its selected Parent Type. For example, a Company Flow can access company fields, while a Contact Flow can access contact fields.

Relationship fields can also be used in any Flow, regardless of Parent Type, allowing you to connect additional records such as Companies, Contacts, Projects, Tickets, or other Flows when needed.

Graph behavior is separate from Parent Type and is based on the type of graph being used:

• Project graphs (Prospects, Sales Projects, Account Growth Projects, Tickets, and Flows) display records linked to the Flow Project through relationship fields.
• Contact graphs display contacts that have been added as stakeholders on the Flow Project.
• Activity and Document graphs display activities and documents that belong to the Flow Project itself.

Because of this, relationship fields play an important role when building reports inside Flows. If a record is not connected to the Flow Project through a relationship field, it will not be included in Project graphs.

Company Parent Type

Choose this when your Flow is related to an organization rather than a specific person.

This is ideal for:

• Customer onboarding and implementation
• Service or delivery projects
• Strategic account initiatives
• Long-term customer success workflows

Why use this?

It ensures everyone interacting with a company has visibility into shared processes and responsibilities, reducing handover issues and missed steps.

How data and reporting work

Flow Projects with a Company Parent Type have access to:

• process fields
• company fields
• stakeholder fields

Graph behavior is the same for all Parent Types. See Data Availability and Reporting in Flows above for details on how graphs are scoped.

Contact Parent Type

This is the right option when the process focuses on an individual person - typically a prospect, buyer, or stakeholder.

This is ideal for:

• Recruitment processes
• Candidate management
• Individual onboarding or training
  

Why use this?

It keeps workflows personal and targeted, ensuring your actions stay aligned with an individual's role.

How data and reporting work

Flow Projects with a Contact Parent Type have access to:

• process fields
• contact fields
• stakeholder fields

Graph behavior is the same for all Parent Types. See Data Availability and Reporting in Flows above for details on how graphs are scoped.

User Parent Type

Use this type when the Flow is tied to an internal team member - typically to support individual routines or responsibilities.

This is ideal for:

• Employee onboarding
• Internal training and learning
• Personal workflows and recurring routines

Why use this?

It helps team members stay organized and consistent in their day-to-day work, even outside of sales opportunities.

How data and reporting work

Flow Projects with a User Parent Type have access to:

• process fields
• user fields

Graph behavior is the same for all Parent Types. See Data Availability and Reporting in Flows above for details on how graphs are scoped.

Automatic Access for Parent Users

For Flow Processes with the User Parent Type, a setting in the Process Settings allows you to automatically grant view access to the assigned Parent User.

When the Grant Access to Parent User toggle is enabled, the Parent User is automatically able to view the Flow Project they are responsible for. This toggle is available for all Flows with a Parent Type of User, and it is enabled by default for newly created Flow Processes of this kind.

With this setting active, the Parent User does not need to be manually added to the project to gain access. This feature simplifies access management and ensures that responsible team members always have visibility into their assigned Flows.

No Parent Type

If your workflow doesn’t need to be tied to a specific entity, select “None.” This is useful for general-purpose Flows or templates.

This is ideal for:

• Marketing campaigns and webinars
• Product development and sprint planning
• Internal operations
• Team-wide initiatives that aren't centered around a specific company, contact, or user

Why use it?

It gives you the flexibility to create repeatable structures that are reused across different contexts or teams.

How data and reporting work

Flow Projects without a Parent Type have access to:

• process fields

Graph behavior is the same for all Parent Types. See Data Availability and Reporting in Flows above for details on how graphs are scoped.