Method CRM becomes much more powerful when you stop treating it like a fixed CRM and start shaping it around your actual workflow. If your team needs to track a process that does not fit neatly into the default screens, you can build a custom app in Method CRM without writing code.
In the video, the example app tracks potential deals for influencer or brand collaborations. The business case is simple: we need a place to manage the lifecycle of each possible deal, see where it stands, and capture the key details needed to move it forward.
The same pattern works for many Method CRM builds, including sales pipelines, project intake, service requests, vendor onboarding, job tracking, or any custom process that needs a clean front-end experience on top of Method data.
Start With the Business Process
Before touching the screen designer, define what the app needs to track.
For the potential deals example, the app needs to answer questions like:
- What is the deal called?
- Who is the contact?
- What stage is the deal in?
- What is the estimated amount?
- What type of opportunity is it?
- Where did the lead come from?
- What notes or description should be stored?
This matters because a custom app should not start as a design exercise. It should start as a workflow decision. Once you know the process, the app structure becomes much easier to build.
Create the Custom App
From the Method CRM dashboard, use the add or remove apps area and choose the option to create a custom app.
Method will ask for a few setup details:
- an app icon
- the app name
- the starting screen name
- the base table
In the example, the app is named Potential Deals and uses the Opportunity table as the base table.
That table choice is important. You do not always need to create a brand-new custom table. If Method already has a table that matches the data relationship, using the existing table can save time and keep the app connected to the rest of the CRM.
Choose the Right Base Table
The base table controls where records are stored and what fields are available on the screen.
For a deal-tracking app, the Opportunity table is a practical fit because it already supports pipeline-style records. That means you can use existing opportunity fields instead of recreating the same structure manually.
A good rule of thumb:
- use an existing Method table when it already represents the record type
- create a custom table when the process is truly unique
- avoid custom tables just because they feel cleaner at first
The simplest durable setup is usually the one that uses Method's existing data model where it fits.
Build the List Screen
After the app is created, the starting screen may be blank. That is expected. Method gives you the app container, but you still need to design what the screen should show.
For a list screen, add a section and place a grid inside it. The grid becomes the main list of records for the app.
Then choose the columns users need to scan quickly. In the example, useful columns include:
- deal name
- contact
- stage
- potential close date
- amount
- opportunity type
This list screen is the operational home base. Users should be able to open the app and immediately understand what deals exist and what needs attention.
Clean Up the Grid Columns
Once the fields are added, adjust the grid so it is readable.
A few small cleanup steps make a big difference:
- put the most important column first
- rename captions so they read naturally
- show the contact name instead of an internal ID
- format dates as short dates
- format amounts as numbers with separators and decimal places
This is the kind of detail that separates a usable Method CRM app from a rough internal database screen. Users should not have to translate field names or decode IDs while doing their work.
Use Browser Tabs While Customizing
A simple productivity tip from the video is to duplicate the browser tab while building.
Keep one tab open in the screen designer and another tab open on the live screen. After each meaningful change, save and refresh the front-end tab.
That gives you fast feedback while you build. You can catch spacing issues, confusing captions, and layout problems before you go too far.
Add Navigation Buttons
A custom app needs more than fields and grids. Users need clear navigation.
On the list screen, add a header or navigation section with actions such as:
- Back
- New Potential Deal
The back button can use the action editor to return through browser history. The new-record button should navigate to the edit screen and clear the screen instead of loading an existing active record.
That distinction matters. If you are creating a new record, there is no saved record ID yet. Clearing the screen gives the user a blank form instead of accidentally editing an existing opportunity.
Create the New and Edit Screen
Next, create a second screen for adding and editing potential deals.
In the example, the screen is based on the Opportunity table and includes sections for:
- header
- main fields
- footer
- hidden controls
This structure is worth reusing. The header gives users context, the main section stores the form, the footer holds save actions, and the hidden section gives you a place for behind-the-scenes controls or reusable logic later.
Design the Header
A clear header helps users understand where they are.
The example uses:
- an icon that matches the app
- a title such as Potential Deal
- a back button
- a bottom border to visually separate the header from the form
These are small layout choices, but they make the screen feel intentional. Method CRM screens are easier to adopt when they look like a real business app, not just a collection of dragged fields.
Add Fields From the Table, Not Generic Inputs
When adding the form fields, use fields from the Opportunity table rather than generic text inputs whenever possible.
This is a key Method CRM concept.
A table field knows where its value should be saved. A generic input control does not automatically know which database field it belongs to unless you add extra actions to map it.
For this screen, practical fields include:
- Name
- Contact
- Stage
- Type
- Amount
- Lead Source
- Description
Using table fields keeps the screen simpler and makes the save process more reliable.
Organize the Form Into Columns
For a cleaner layout, split the main section into two columns.
Put related fields together and leave enough spacing around each row. In the example, the screen is adjusted with padding so the fields do not feel cramped.
For longer notes, increase the number of input lines on the description field. A description box should feel like a place for real context, not a tiny single-line field that discourages useful notes.
Add a Footer and Save Button
The form needs a clear save action. Add a footer section, give it enough padding, and add a top border so it feels separated from the main form.
Then add a Save or Save and Back button.
In the action editor, use the save action to save the screen's bound fields back to the Opportunity table. If you have validation rules on the screen, enable validation before saving so Method checks those rules first.
That gives the app a simple end-to-end flow:
- Open the custom app.
- View existing potential deals in a grid.
- Click New Potential Deal.
- Enter the record details.
- Save the record to the Opportunity table.
Why This Pattern Works
The durable pattern is straightforward:
- Define the business process.
- Choose the best base table.
- Build a list screen for visibility.
- Build an edit screen for data entry.
- Use table fields instead of unnecessary generic controls.
- Add navigation with the action editor.
- Add save logic and validation.
- Review the live screen as you build.
Once you understand this structure, you can reuse it for almost any custom Method CRM app.
Common Mistakes to Avoid
Creating a custom table too early
If Method already has a table that fits, start there. Custom tables are useful, but they add maintenance when they are not needed.
Showing internal IDs to users
Record IDs and lookup IDs may be useful to the system, but users usually need names, statuses, dates, and amounts.
Using generic controls for saved data
If the value should save directly to a table field, use the field control. Generic inputs are better for temporary values, filters, or special action-driven workflows.
Forgetting the user flow
A list screen without a new button, an edit screen without a back button, or a save button without clear behavior will frustrate users quickly.
Final Thoughts
Building a custom app in Method CRM is not about adding as many fields as possible. It is about turning a real workflow into a clean screen that people can use every day.
Start with the process, use the right base table, design a useful list screen, create a focused edit screen, and let Method handle the data binding wherever it can.
If you are planning a larger Method CRM customization, this is the foundation. Once the app structure is solid, you can layer in dropdown management, editable grids, calculations, automations, and reporting without rebuilding the core workflow.
If you want help designing a Method CRM app around your actual sales or service process, book a free strategy call and let’s map it out.