Tenancy Model Scoping Best Practices

With multi-tenancy implemented, what's the best practice to scope Eloquent models to a Tenant Is this the correct approach? I don't see any documentation on creating models/migrations with multi-tenancy and any opinionated advice on this would be great.
Schema::create('invitations', function (Blueprint $table) {
$table->foreignIdFor(Organization::class)
->constrained()
->cascadeOnDelete();

$table->string('email')->index();

$table->foreignId('invited_by_id')
->constrained('users')
->cascadeOnDelete();

...
});
Schema::create('invitations', function (Blueprint $table) {
$table->foreignIdFor(Organization::class)
->constrained()
->cascadeOnDelete();

$table->string('email')->index();

$table->foreignId('invited_by_id')
->constrained('users')
->cascadeOnDelete();

...
});
class Invitation extends Model
{
public function organization(): BelongsTo
{
return $this->belongsTo(Organization::class);
}

public function inviter()
{
return $this->belongsTo(User::class, 'invited_by_id');
}
class Invitation extends Model
{
public function organization(): BelongsTo
{
return $this->belongsTo(Organization::class);
}

public function inviter()
{
return $this->belongsTo(User::class, 'invited_by_id');
}
1 Reply
Tim van Heugten
Tim van Heugten2mo ago
If you enable tenancy in Filament with Organization as the tenant model and in your example you create an Invitations resource, Filament will expect the relation (and column) you created in your example and else throw an error. Tenancy is very case specific. I always tend to add a tenant id column to most models, even when they are ‘sub relations’ to a model that already has a tenant id. It’s redundant, but often make life easier in the future. Filament scopes most queries automatically, but not all. Always check and test you are not leaking data between tenants (think selects in forms, possible values for filters, etc).

Did you find this page helpful?