> For the complete documentation index, see [llms.txt](https://docs.work-relay.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.work-relay.com/work-relay-overview/key-concepts.md). # Key concepts This article provies a quick insight into the basics of Work-Relay. There are few concepts that are absolutely essential to understand when you're trying to imagine and put together a consistent & cohesive business process automation with Work-Relay. The very structure of this documentation follows that same layering: Processes Forms Automations Administration Functional ## Processes & process instances A process is a collection of steps executed in a given order - not just consequent, put parallel, too. Each step is assigned to a user, group, etc. for completion. A step would often have a number of operations configured to run when it's being activated or completed: someone may need to receive an email, or a record needs to be updated etc. You will find lots of informations on Processes in the respective site section; they're a powerful and deeply elaborated tool. The very essence of a Process is being an "engine" that defines which tasks (steps) generate in what order. Process itself is an abstract definition. To acutally run it, you need a Salesforce record. When a process is kicked off on a record, an instance of the process is created. For example, you could have an instance of "IT and Equipment Setup" process running on an Employee record. In addition to "IT and Equipment Setup", this same Employee record could host (be a data source for) an instance of "Compliance and Legal Training". Or - you could have an instance of larger-scope "Employee onboarding" process running on that Employee record, while "IT and Equipment Setup" and "Compliance and Legal Training" could be subprocesses kicking off at the steps of "Employee onboarding" and run sequentially or in parallel - depending on how you design it. ## The way users interact with tasks Once there is an instance of a Process running on a Record, it will start populating tasks assigned to Users. There are two main places where the users will interact with their tasks (complete them): ### Dashboard Users will see their tasks on the Dashboard, where a card will represent an active Step from an Instance of a Process. Once they click a card, they will see the variety of information related to this active step, including its layout. On th Dashboard, a User will see all tasks they are authorized to see, from all Instances defined in the Org - with the ability to apply filters. See details on the main Dashboard, and other dashboards that come with the App, [here](/functional/dashboards/task-manager-dashboard.md). ### Process progress component This component will represent the entire Instance of a Process that's running on a given record. The most regular way to place this component, is on the Record page. It will show the past, present (active) steps, and the future steps of the given Instance. Active steps will be available for interaction, if the user has the permission to do so (if they can complete the given step). See details [here](/functional/process-progress-component/progress-component-overview.md). Other Work-Relay component that the users may interact with, is covered in [Functional](https://docs.work-relay.com/functional/) site section. ## Custom layouts Okay - so, once the Administrator / Work-Relay designer have defined the Process, and the Instance of it was kicked off on a Record, the Assignees start getting their tasks and can interact with them on the Dashboard, or on a record page with Workflow Line added to it. Default layout for a step would be the Salesforce layout associated with the given Object in Salesforce. When opening an active step from a Process running on the Case object and navigating to the Layout tab, the user will see the same fields as on the Case record itself. Yet - sometimes, to complete their task, a User will need only several fields from the Record, and the rest will be a mere distraction. They would not need to see the entire record layout when opening their task on the Dashboard! This is when a Form can be associated with a given step in the process. It may only have those exact fields the User needs. But the forms can do much more than just displaying fields - they are an elaborated tool where you could have conditional styles, lists, virtual fields; Forms allow for building highly dynamic interfaces that can be even used stand-alone (ex. on a Record page). That's why there's an entire section of this Documentation dedicated to [Forms](https://docs.work-relay.com/forms/), but other custom [layout options](/processes/process-steps/process-step-settings/process-step-layouts.md) are available, too. ## Automations As mentioned earlier, there's a number of actions in the box that can be associated with completing a step. The user may simply complete their task, but configuration built behind the scenes in the Process builder, will define a number of other actions that will to be executed: an email sent to someone, some record created etc. Yet, sometimes something that goes beyond the pre-defined selection of actions needs to be done: ex. a Salesforce Autolaunched flow invoked, or a data operation defined in legacy Apex code executed. This is when using Work-Relay API or one of the Apex interfaces from the box need to be used. Also, sometimes you may be good with defining an action in a way that Work-Relay allows to configure, but you need to execute it outside of the context of process step completion: ex. it needs to invoked from a Form. This is the case for Work-Relay [Global actions](/automations/global-actions-and-action-groups/basics.md). The entire range of options to invoke or build custom logic to interact with data in Salesforce, is covered in [Automations](https://docs.work-relay.com/automations/).